swiftlang
Add #_objectFileFormat compilation conditional
This implements the relevant part of the "Section Placement" proposal (draft: https://github.com/kubamracek/swift-evolution/blob/section-placement-control/proposals/0nnn-section-control.md, forum thread: https://forums.swift.org/t/pitch-3-section-placement-control/77435). Namely the ability to conditionalize on the object file format that the compiler is targeting (MachO, ELF, COFF of Wasm).
Adding with an underscored name (#_objectFileFormat) until the proposal is codified.
rdar://147505228
Should we consider gating this behind an experimental feature flag?
I'm happy to do that if we deem that necessary, though all the other existing not-yet-ratified compilation conditions (e.g. pointerBitWidth) don't do that and just use an underscore.
https://github.com/swiftlang/swift-syntax/pull/3027
@swift-ci please test
Should we consider gating this behind an experimental feature flag?
Swift Testing will need to make use of this to support Embedded Swift, and requiring an experimental flag will make it more difficult to do so. (When it gets formally featurized, we can eagerly adopt the final version.)
https://github.com/swiftlang/swift-syntax/pull/3027
@swift-ci please test
https://github.com/swiftlang/swift-syntax/pull/3027
@swift-ci please test
Are there any other object formats that LLVM supports? Should we add cases for them even if Swift itself hasn't added toolchain support?
Edit: The following are all the cases in the object format enum in the Swift repo:
enum ObjectFormatType {
UnknownObjectFormat,
COFF,
DXContainer,
ELF,
GOFF,
MachO,
SPIRV,
Wasm,
XCOFF,
};
So it may make sense to just switch over the whole enum (with getObjectFormat()).
Are there any other object formats that LLVM supports? Should we add cases for them even if Swift itself hasn't added toolchain support?
Edit: The following are all the cases in the object format enum in the Swift repo:
enum ObjectFormatType { UnknownObjectFormat, COFF, DXContainer, ELF, GOFF, MachO, SPIRV, Wasm, XCOFF, };So it may make sense to just switch over the whole enum (with
getObjectFormat()).
I think it's probably undesirable to go beyond the 4 object file formats that Swift targets today, because (1) we'd have to lock down the specific spelling of those and (2) it would suggest that the compiler is actually capable of producing valid object files in these formats, but that's almost certainly not true until someone actively builds that support.
it would suggest that the compiler is actually capable of producing valid object files in these formats, but that's almost certainly not true until someone actively builds that support.
I don't know if I agree here. However, we do in a number of places currently just abort if you use a different object file format. Some of these are unlikely to ever be supported (e.g. DXContainer and SPIRV), so adding the full coverage really doesn't add much value, but does add noise.
https://github.com/swiftlang/swift-syntax/pull/3170 @swift-ci please test
https://github.com/swiftlang/swift-syntax/pull/3170 @swift-ci please test
https://github.com/swiftlang/swift-syntax/pull/3170 @swift-ci please test macOS platform