Tracking issue for turning unstable / incorrect `-Ctarget-feature` into a hard error

[RalfJung]

When -Ctarget-feature was introduced, we allowed passing arbitrary LLVM target features. This turned out to be a mistake:

• Some target features alter the ABI, so using them in -C flags is unsound as different crates with different values for those flags may be linked together.
• LLVM can rename / remove target features, which is in conflict with our stability policy.

For #[target_feature] and cfg(target_feature), we were a lot more careful, and we only allow/expose explicitly stabilized target features. This issue is tracking our move towards doing the same with -Ctarget-feature. This means it will become a hard error to:

• Use a target feature that we don't know at all.
• Use a target feature that we know but is unstable.
• Use a target feature that we know but is marked as "internal-only", i.e. it is not meant to be stabilized and just tracked for internal compiler purposes. This is usually done because the target feature alters the ABI or because LLVM chose to expose something as a target feature that rustc exposed via other knobs.
• Use a target feature that we know and that is stable, but that would alter the ABI of the current target.

The intended immediate replacement for all of these is -Zllvm-target-feature. This is a target modifier, so we ensure that there are no ABI differences across crates that are being linked together. However, that also means it depends on -Zbuild-std to avoid ABI differences with the pre-built standard library. This means we will likely wait for both of those to stabilize before we turn this warning into a hard error.

The other possible replacement, at least for target features that actually are harmless on the ABI side, is to stabilize the relevant target features. If you cannot use nightly for some reason, this is the best way forward for you. Please let us know which target features are causing this FCW, and ideally help us stabilize them. :)

[abhinav-phi]

Hi! I'd like to work on this.

Plan: I'll reproduce the reported behavior, trace the faulty logic, patch it, and add a test covering the reported case.

Could you please assign this issue to me? Thanks!

/assign take

[RalfJung]

This is not a request for anyone to work on anything. It is a tracking issue. Did you read the issue description? There's nothing to patch here at the moment.

[jieyouxu]

Hi there @abhinav-phi,

Your comments looks like automated submissions, which is not permitted.

We are thus suspending you as per our policies [1], [2] and contribution standards [3]. You can contact the moderation team to discuss and possibly reconsider your suspension.

Thanks for understanding.

Jieyou in the name of the mod team

[djc]

I ran into some warnings like this from running rustc +nightly --print=cfg, which seems surprising?

djc-studio-2025 platforms-4.2.0 platforms $ rustc +nightly --print=cfg --target=xtensa-esp32s3-none-elf
'esp32s3' is not a recognized processor for this target (ignoring processor)
'esp32s3' is not a recognized processor for this target (ignoring processor)
warning: target feature `windowed` must be enabled to ensure that the ABI of the current target can be implemented correctly
  |
  = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>

warning: target feature `exception` must be enabled to ensure that the ABI of the current target can be implemented correctly
  |
  = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>

Surely no specific target features are required to get at the target's cfg features?

[RalfJung]

Seems like something is wrong with the xtensa targets. The ABI we use requires the "windowed" extension but we're not enabling that in the target spec and apparently it is not enabled by default in LLVM. Cc @MabezDev