`rustc`: `target_features`: allow for `cfg`-only stable `target_features` by romancardenas · Pull Request #155962 · rust-lang/rust

romancardenas · 2026-04-29T10:20:51Z

This PR introduces a new stabilization level for target_features: CfgOnlyStable. The motivation is allowing the Rust compiler to expose target_features of targets so users can use cfg(target_feature = "feature") for conditional blocks depending on target features. However, CfgOnlyStable cannot be used for #[target_feature(enable = "feature")], as this is still considered unstable. Accordingly, the compiler will still raise an error if these expressions are used on stable.

This PR relates partially to #150257. As discussed, for RISC-V targets, having the "d", "e", and "f" target features exposed will allow baremetal developers to adapt the code depending on the target's properties.

r? @RalfJung

rustbot · 2026-04-29T10:20:57Z

r? @nikomatsakis

rustbot has assigned @nikomatsakis.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

rustbot · 2026-04-29T10:21:32Z

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

RalfJung

Thanks! This is probably the easiest way to do it. It's not super clean since it cannot represent "feature is allowed in cfg but strictly forbidden otherwise", so the entire thing will need a refactor eventually... but I can't ask you to do that now so let's just go with this.

@rustbot author

View changes since this review

RalfJung · 2026-04-30T12:56:41Z

                            reason,
                        });
-                    } else if stability.requires_nightly().is_some() {
+                    } else if stability.requires_nightly(true).is_some() {


Suggested change

} else if stability.requires_nightly(true).is_some() {

} else if stability.requires_nightly(/* in_cfg */ false).is_some() {

This is where we emit warnings for unstable things in -Ctarget-feature. Yes it's pretty hacky to do that as a side-effect of constructing the cfg data... codegen backend initialization is a terrible spaghetti mess and someone decided this was the place to put that check. 🤷 (It's probably here to avoid emitting the warnings multiple times, or something like that.)

RalfJung · 2026-04-30T12:56:52Z

                reason,
            });
-        } else if let Some(nightly_feature) = stability.requires_nightly()
+        } else if let Some(nightly_feature) = stability.requires_nightly(false)


Suggested change

} else if let Some(nightly_feature) = stability.requires_nightly(false)

} else if let Some(nightly_feature) = stability.requires_nightly(/* in_cfg */ false)

If I'm not wrong, here is the only place where the new error message should be triggered right? I push an additional commit with the new error message, if needed.

I don't understand the question. There are 3 places where we query feature stability, corresponding to -Ctarget-feature, #[target_feature], and cfg(target_feature), respectively. Only one of them should set in_cfg to true.

In your review, you mentioned that:

It's not super clean since it cannot represent "feature is allowed in cfg but strictly forbidden otherwise", so the entire thing will need a refactor eventually...

If this PR is OK so far, I can try to add a new error message near lines 65 and 318, which corresponds to the check for #[target_feature] and -Ctarget-feature, respectively.

I am still confused. I did mention that, yes. What does it have to do with the diff I suggested here?

To resolve that concern, we'd need a more fundamental refactor of the Stability type, into something more like

struct TargetFeatureInfo { for_cfg: Stability, for_toggle: Stability, }

That's a lot more work so I am not expecting / asking you to do it in this PR.

Sorry for the confusion, it has nothing to do with the particular diff you suggested. It was just for me to know where error/warning messages were triggered. I will keep discussing this in a separate comment.

RalfJung · 2026-04-30T12:56:59Z

                if allow_unstable
                    || (gate.in_cfg()
-                        && (sess.is_nightly_build() || gate.requires_nightly().is_none()))
+                        && (sess.is_nightly_build() || gate.requires_nightly(true).is_none()))


Suggested change

&& (sess.is_nightly_build() || gate.requires_nightly(true).is_none()))

&& (sess.is_nightly_build() || gate.requires_nightly(/* in_cfg */ true).is_none()))

rustbot · 2026-04-30T13:07:40Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

romancardenas · 2026-05-04T08:14:49Z

@rustbot ready

…y stable features

romancardenas · 2026-05-04T15:32:46Z

I pushed a commit that includes a basic error handling for printing error and warning messages that explicitly mention a target feature that is cfg-stable but unstable otherwise. It is not as elaborate as should probably be, but maybe for this first PR is good enough.

Let me know if you don't like the approach and I will revert the latest commit.

RalfJung · 2026-05-04T16:42:47Z

I like it. :)

I'm a bit nervous about not having a test for this, but I am also not sure how a test could work. We'd need some sort of dummy feature that's guaranteed to always remain cfg_stable_toggle_unstable... but we don't actually want to have such a feature available on stable.^^

@bors r+ rollup

rust-bors · 2026-05-04T16:42:50Z

📌 Commit ee9a01a has been approved by RalfJung

It is now in the queue for this repository.

@RalfJung

…et-feature, r=RalfJung `rustc`: `target_features`: allow for `cfg`-only stable `target_features` This PR introduces a new stabilization level for `target_features`: `CfgOnlyStable`. The motivation is allowing the Rust compiler to expose `target_features` of targets so users can use `cfg(target_feature = "feature")` for conditional blocks depending on target features. However, `CfgOnlyStable` cannot be used for `#[target_feature(enable = "feature")]`, as this is still considered unstable. Accordingly, the compiler will still raise an error if these expressions are used on stable. This PR relates partially to rust-lang#150257. As discussed, for RISC-V targets, having the `"d"`, `"e"`, and `"f"` target features exposed will allow baremetal developers to adapt the code depending on the target's properties. r? @RalfJung

…uwer Rollup of 10 pull requests Successful merges: - #155848 ([doc]: Revert `core::io::ErrorKind` doc changes) - #155855 (Remove unnecessary `get_unchecked`) - #155543 (docs(unstable-book): Document const generics features) - #155962 (`rustc`: `target_features`: allow for `cfg`-only stable `target_features`) - #156043 (c-variadic: gate `va_arg` on `c_variadic_experimental_arch`) - #156082 (Move tests associated types) - #156092 (Clean up `TyCtxt::needs_crate_hash` usage and rename it to `needs_hir_hash`.) - #156104 (Relax `T: Sized` bound on `try_as_dyn` / `try_as_dyn_mut`) - #156128 (.mailmap: prefer matching just based on commit emails) - #156135 (Remove most uses of def_id_to_node_id)

rustbot assigned nikomatsakis Apr 29, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 29, 2026

rustbot assigned RalfJung and unassigned nikomatsakis Apr 29, 2026

romancardenas mentioned this pull request Apr 30, 2026

Tracking Issue for riscv_target_feature #150257

Open

4 tasks

RalfJung reviewed Apr 30, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2026

romancardenas force-pushed the cfg-only-stable-target-feature branch from bb0826a to 109fc56 Compare May 4, 2026 08:11

rustc: target_features: allow for cfg-only stable target_features

df8d029

romancardenas force-pushed the cfg-only-stable-target-feature branch from 109fc56 to df8d029 Compare May 4, 2026 08:13

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 4, 2026

rustc: target_features: adapt compile errors and warnings for cfg-onl…

ee9a01a

…y stable features

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 4, 2026

JonathanBrouwer mentioned this pull request May 4, 2026

Rollup of 10 pull requests #156153

Open

	} else if stability.requires_nightly(true).is_some() {
	} else if stability.requires_nightly(/* in_cfg */ false).is_some() {

	} else if let Some(nightly_feature) = stability.requires_nightly(false)
	} else if let Some(nightly_feature) = stability.requires_nightly(/* in_cfg */ false)

	&& (sess.is_nightly_build() \|\| gate.requires_nightly(true).is_none()))
	&& (sess.is_nightly_build() \|\| gate.requires_nightly(/* in_cfg */ true).is_none()))

Uh oh!

Conversation

romancardenas commented Apr 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 29, 2026

Uh oh!

rustbot commented Apr 29, 2026

Uh oh!

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

romancardenas May 4, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

romancardenas May 4, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung May 4, 2026

Choose a reason for hiding this comment

Uh oh!

romancardenas May 4, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Apr 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rustbot commented Apr 30, 2026

Uh oh!

romancardenas commented May 4, 2026

Uh oh!

romancardenas commented May 4, 2026

Uh oh!

RalfJung commented May 4, 2026

Uh oh!

rust-bors Bot commented May 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

romancardenas commented Apr 29, 2026 •

edited by rustbot

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung Apr 30, 2026 •

edited

Loading

RalfJung May 4, 2026 •

edited

Loading