Repository navigation
Tracking Issue for cfg-target-abi #80970
Description
Activity
-
I came across
x86_64_fortanix_unknown_sgxand I'm wondering ifsgxshould be changed from beingenvtoabi? I assume not, but I figured I'd ask. -
I'm also curious about
aarch64_unknown_none_softfloat: shouldsoftfloatbe listed as ABI? I figure it's already covered by target feature-fp-armv8. -
I noticed that
darwinpcsis passed as-target-abito clang for arm64 iOS targets. So now I'm wondering if themacabitargets should actually betarget_abiofdarwinpcsandtarget_envofmacabi.
-
rustc --print cfgshould printtarget_abi. Right now,rustc --target arm-unknown-linux-gnueabi --print cfgandrustc --target arm-unknown-linux-gnueabihf --print cfghave the same output.@nvzqz For
x86_64-fortanix-sgx, I think "sgx" should remain the "os" and "fortanix" should be moved from "vendor" to either "abi" or "env".Implementation in progress at #86922
How does this interact with custom target json files? Something like https://github.com/embed-rs/stm32f7-discovery/blob/e4c00f8536d7c6b167c9cf5574d0fe8e1e0cfcff/stm32f7.json
For anyone wanting to act on the ready-to-stabilize label: also note the
FIXMEcomments in the target files, added in #86922, and make the corresponding adjustments when stabilizing. That PR will also need therelnoteslabel.Ended up here precisely because I wanted to distinguish iOS device and simulator targets in
cfg. I'm not sure what the high-level difference is betweentarget_envandtarget_abi, but by putting the iOS variants intarget_abi, I can't get at them on stable.Stabilization report
I propose to stabilize
#[cfg(target_abi = "...")], This implements RFC-2992 (cfg-target-abi). The implementation was completed in #86922 and this tracking issue was subsequently marked as ready for stabilization by @joshtriplett.Summary
This stabilizes the
cfgoption calledtarget_abi:#[cfg(target_abi = "macabi")]And
target_abiis also shown when using--print=cfg(output snipped for length):> rustc --print=cfg --target aarch64-apple-ios-sim target_abi="sim" target_arch="aarch64" target_env="" target_os="ios" target_vendor="apple"Without
target_abi, cfgs are limited totarget_arch,target_vendor,target_os, andtarget_env. However, some targets are only differentiated by their abi and thus it's necessary to resort to parsing the full target string in a build script when there's a need to disambiguate. For example, the following targets are the same if only using stabletarget_*cfgs:aarch64-apple-iosandaarch64-apple-ios-sim(arch: "aarch64", vendor: "apple", os: "ios", env: "")x86_64-pc-windows-gnullvmandx86_64-pc-windows-gnu(arch: "`x86_64", vendor: "pc", os: "windows", env: "gnu")
Notes
The
target_abidefaults to""(the empty string) and most targets don't set it. This is similar totarget_envwhere if it's not needed for disambiguation then it's often not set.In the future
target_abicould be an array of zero or more properties that affect the ABI (e.g.softfloatmay be combined with other ABI properties), However, this feature can be added later without breaking compatibility.I guess an alternative to stabilizing this would be to extend
target_envto be an array of values that includes abi and other things.Tests
tests/ui/cfg/cfg-target-abi.rs
tests/ui/check-cfg/well-known-values.rsDocumentation
Stabilization PR
#119590. This also addresses the FIXMEs left by #86922, where existing (tier 3) values need to change once cfg_target_abi is stable.
Reacted by Mateusz Mikuła and Mads Marquart@rustbot labels +I-lang-nominated
Nominating on behalf of @ChrisDenton on the basis of the stabilization report above.
16 remaining items
- added a commit that references this issue
on Feb 17, 2024 - added a commit that references this issue
on Feb 18, 2024 The
target_abidefaults to "" (the empty string) and most targets don't set it.target_osuses"none"instead of the empty string, maybe that's actually the saner value?The empty string feels to me more like "no-one thought about what to put here so
rustcjust defaulted to something, but you can't actually rely on#[cfg(target_abi = "")]working".Perhaps, if we want
target_abito potentially be multiple values, maybe we shouldn't even emit a cfg for when there is no target ABI? That way, people will be forced to write e.g.#[cfg(not(target_abi = "sim"))]if they want to write code for non-simulator targets, instead of#[cfg(target_abi = "")], which is probably more portable, e.g. in case we get something that sets bothtarget_abi = "macabi"andtarget_abi = "sim"(hypothetical, but you get the idea)?@madsmtm I think
""is consistent with how the ABI appears in target triples.target_osuses"none"because of target names likex86_64-unknown-none.target_abiuses""rather than"none"because we don't, for instance, writex86_64-unknown-linux-muslnonethe way we writearmel-unknown-linux-musleabihf.I think it's valid to say "there isn't a special ABI", rather than (for instance) having to enumerate ABIs.
Reacted by Mads MarquartThe final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
- added a commit that references this issue
on Feb 25, 2024
This is a tracking issue for the RFC "Add
target_abiconfiguration" (rust-lang/rfcs#2992).The feature gate for the issue is
#![feature(cfg_target_abi)].About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
instructions?)
Unresolved Questions
Implementation history