Tracking Issue for cfg-target-abi

This is a tracking issue for the RFC "Add target_abi configuration" (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

Implement the RFC (cc @rust-lang/lang -- can anyone write up mentoring
instructions?)
Fix up tier 3 targets that have target ABIs embedded in their target env (target_env should not include ABI information #78791)
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

I came across x86_64_fortanix_unknown_sgx and I'm wondering if sgx should be changed from being env to abi? I assume not, but I figured I'd ask.
I'm also curious about aarch64_unknown_none_softfloat: should softfloat be listed as ABI? I figure it's already covered by target feature -fp-armv8.
I noticed that darwinpcs is passed as -target-abi to clang for arm64 iOS targets. So now I'm wondering if the macabi targets should actually be target_abi of darwinpcs and target_env of macabi.

rustc --print cfg should print target_abi. Right now, rustc --target arm-unknown-linux-gnueabi --print cfg and rustc --target arm-unknown-linux-gnueabihf --print cfg have the same output.

@nvzqz

@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

@oli-obk

@oli-obk custom targets like that would specify "abi": "eabihf" to match the underlying LLVM target's ABI. Otherwise #[cfg(target_abi = "eabihf")] should not match the custom target.

With #86922 merged, I think this is ready to stabilize.

For anyone wanting to act on the ready-to-stabilize label: also note the FIXME comments in the target files, added in #86922, and make the corresponding adjustments when stabilizing. That PR will also need the relnotes label.

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 between target_env and target_abi, but by putting the iOS variants in target_abi, I can't get at them on stable.

@joshtriplett

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 cfg option called target_abi:

#[cfg(target_abi = "macabi")]

And target_abi is 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 to target_arch, target_vendor, target_os, and target_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 stable target_* cfgs:

aarch64-apple-ios and aarch64-apple-ios-sim (arch: "aarch64", vendor: "apple", os: "ios", env: "")
x86_64-pc-windows-gnullvm and x86_64-pc-windows-gnu (arch: "`x86_64", vendor: "pc", os: "windows", env: "gnu")

Notes

The target_abi defaults to "" (the empty string) and most targets don't set it. This is similar to target_env where if it's not needed for disambiguation then it's often not set.

In the future target_abi could be an array of zero or more properties that affect the ABI (e.g. softfloat may 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_env to 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.rs

Documentation

rust-lang/reference#1446

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.

@rustbot

@rustbot labels +I-lang-nominated

Nominating on behalf of @ChrisDenton on the basis of the stabilization report above.

Rollup merge of rust-lang#121210 - madsmtm:fix-target-abi-i386-apple-…

Unrolled build for rust-lang#121210

Rollup merge of #121210 - madsmtm:fix-target-abi-i386-apple-ios, r=wo…

The target_abi defaults to "" (the empty string) and most targets don't set it.

target_os uses "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 rustc just defaulted to something, but you can't actually rely on #[cfg(target_abi = "")] working".

Perhaps, if we want target_abi to 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 both target_abi = "macabi" and target_abi = "sim" (hypothetical, but you get the idea)?

@madsmtm

@madsmtm I think "" is consistent with how the ABI appears in target triples. target_os uses "none" because of target names like x86_64-unknown-none. target_abi uses "" rather than "none" because we don't, for instance, write x86_64-unknown-linux-muslnone the way we write armel-unknown-linux-musleabihf.

I think it's valid to say "there isn't a special ABI", rather than (for instance) having to enumerate ABIs.

The 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.

Rollup merge of rust-lang#119590 - ChrisDenton:cfg-target-abi, r=Nils…

Unrolled build for rust-lang#119590

Rollup merge of rust-lang#139451 - madsmtm:apple-target-env-abi, r=we…

Unrolled build for #139451

Navigation Menu

Repository navigation

Tracking Issue for cfg-target-abi #80970

About tracking issues

Steps

Unresolved Questions

Implementation history

Stabilization report

Summary

Notes

Tests

Documentation

Stabilization PR

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for cfg-target-abi #80970

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

nvzqz commented on Feb 7, 2021

joshtriplett commented on Jul 2, 2021

joshtriplett commented on Jul 6, 2021

joshtriplett commented on Jul 7, 2021

oli-obk commented on Jul 8, 2021

nvzqz commented on Mar 18, 2022

joshtriplett commented on Jul 20, 2022

jrose-signal commented on Sep 27, 2023

ChrisDenton commented on Jan 4, 2024

Stabilization report

Summary

Notes

Tests

Documentation

Stabilization PR

traviscross commented on Jan 4, 2024

16 remaining items

madsmtm commented on Feb 24, 2024

joshtriplett commented on Feb 24, 2024

rfcbot commented on Feb 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions