add `unreachable_cfg_select_predicates` lint #149960

folkertdev · 2025-12-13T19:48:31Z

tracking issue: #115585

Split out from #149783. This lint is emitted on branches of a cfg_select! that are statically known to be unreachable. The lint is only emitted when the feature is enabled, so this change specifically does not need an FCP, and the lint will be stabilized alongside the feature (see #149783 (comment)).

rustbot · 2025-12-13T19:48:34Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

rustbot · 2025-12-13T19:48:36Z

r? @WaffleLapkin

rustbot has assigned @WaffleLapkin.
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

Urgau · 2025-12-13T20:55:03Z

The proposed name for this lint seems quite unfortunate to me. When I first read it I though it had something to do with the #[cfg] attribute, like detecting #[cfg] predicates that are unreachable.

I think it would be better include the word "arm" or "cfg_select" in it, to clearly disambiguate it from the other places where cfgs can appear.

Maybe unreachable_cfg_arms or unreachable_cfg_select_arms?

folkertdev · 2025-12-13T21:01:33Z

There is some reasoning for then name at #149783 (comment).

cc @traviscross was there any particular reason for you to leave out the select or arm/branch parts?

traviscross · 2025-12-14T01:35:57Z

The reasoning was:

For match, we call it unreachable-patterns; i.e. we put the focus on the pattern being unreachable rather than the arm. This makes sense; it's more precise. Notably we don't call it unreachable-match-arm-patterns.

Here that would suggest the name unreachable-cfg-predicates, since the constructs on the LHS of each arm are "configuration predicates" and we abbreviate "cfg".

But we have an existing lint, unexpected-cfgs that already uses cfgs to mean "configuration options" (a subset of cfg predicates), so punning a bit and riffing off that system would suggest the name unreachable-cfgs (though as mentioned, unreachable-cfg-predicates is OK too.)

To your point about detecting cfg attributes that are unreachable, I had the same thought when proposing the name, but expected I'd be OK, if we ever did want to lint other kinds of unreachable configuration predicates, using this same name for that.

Sitting with it now, though, I think unreachable-cfg-select-predicates would be OK.

bors · 2025-12-14T09:03:47Z

☔ The latest upstream changes (presumably #146348) made this pull request unmergeable. Please resolve the merge conflicts.

This is emitted on branches of a `cfg_select!` that are statically known to be unreachable.

rustbot · 2025-12-14T14:14:49Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

folkertdev · 2025-12-14T14:16:06Z

I do like unreachable-cfg-select-predicates better, because it is more specific and more accurately reflects where someone might encounter this lint. So, I changed the implementation to use that name now.

WaffleLapkin · 2025-12-15T13:12:49Z

tests/ui/feature-gates/cfg_select.rs

+// `#[feature(cfg_select)]` is a libs feature (so, not a lang feature), but it lints on unreachable
+// branches, and that lint should only be emitted when the feature is enabled.


Q: why should it only lint when the feature is enabled?

Because then no separate FCP is required to merge this lint. At least that is my interpretation of #149783 (comment).

Probably what I had in mind is to go ahead and make it into (or otherwise add) a lang feature gate and then to feature gate the lint itself in the declare_lint!.

WaffleLapkin · 2025-12-15T13:14:23Z

tests/ui/lint/issue-70819-dont-override-forbid-in-same-scope.stderr

+Future breakage diagnostic:
+error: warn(unused) incompatible with previous forbid
+  --> $DIR/issue-70819-dont-override-forbid-in-same-scope.rs:22:13
+   |
+LL |     #![forbid(unused)]
+   |               ------ `forbid` level set here
+LL |     #![deny(unused)]
+LL |     #![warn(unused)]
+   |             ^^^^^^ overruled by previous forbid
+   |
+   = warning: 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 #81670 <https://github.com/rust-lang/rust/issues/81670>
+note: the lint level is defined here
+  --> $DIR/issue-70819-dont-override-forbid-in-same-scope.rs:17:11
+   |
+LL | #![forbid(forbidden_lint_groups)]
+   |           ^^^^^^^^^^^^^^^^^^^^^
+


What happened, how is this change related?

The test has this comment

// If you turn off deduplicate diagnostics (which rustc turns on by default but // compiletest turns off when it runs ui tests), then the errors are // (unfortunately) repeated here because the checking is done as we read in the // errors, and currently that happens two or three different times, depending on // compiler flags. // // I decided avoiding the redundant output was not worth the time in engineering // effort for bug like this, which 1. end users are unlikely to run into in the // first place, and 2. they won't see the redundant output anyway. //@ compile-flags: -Z deduplicate-diagnostics=yes

I believe that the logic here added another time that the error is emitted. That's unfortunate but as the comment mentions it's kind of not worth the engineering effort to fix because it is unlikely that end users ever see this repeated error.

WaffleLapkin · 2025-12-15T13:16:21Z

compiler/rustc_attr_parsing/src/attributes/cfg_select.rs

+    if let Some((underscore, _, _)) = branches.wildcard
+        && features.map_or(false, |f| f.enabled(rustc_span::sym::cfg_select))
+    {
+        for (predicate, _, _) in &branches.unreachable {
+            let span = predicate.span();
+            p.psess.buffer_lint(
+                UNREACHABLE_CFG_SELECT_PREDICATES,
+                span,
+                lint_node_id,
+                BuiltinLintDiag::UnreachableCfg { span, wildcard_span: underscore.span },
+            );
+        }
+    }


This doesn't seem to warn, unless there is a wildcard, why so? Does it not warn in case of

cfg_select! { unix => true, not(unix) => false, windows => false, }

That is correct, it's hard to do better than that. we'd need to actually have some sort of logic solver to do so in general, and even then I think it might misfire if there is some sort of feature flag implication that the checker does not know about.

So the current imlementation is basic but reliable.

folkertdev · 2025-12-15T18:58:17Z

@rustbot ready

folkertdev added the F-cfg_select `#![feature(cfg_select)]` label Dec 13, 2025

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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 Dec 13, 2025

rustbot assigned WaffleLapkin Dec 13, 2025

traviscross added the I-lang-radar Items that are on lang's radar and will need eventual work or consideration. label Dec 14, 2025

add unreachable_cfg_select_predicates lint

20f27e5

This is emitted on branches of a `cfg_select!` that are statically known to be unreachable.

folkertdev force-pushed the cfg-select-unreachable-lint branch from 542a992 to 20f27e5 Compare December 14, 2025 14:14

folkertdev changed the title ~~add unreachable_cfgs lint~~ add unreachable_cfg_select_predicates lint Dec 14, 2025

WaffleLapkin reviewed Dec 15, 2025

View reviewed changes

WaffleLapkin 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 Dec 15, 2025

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 Dec 15, 2025

		// `#[feature(cfg_select)]` is a libs feature (so, not a lang feature), but it lints on unreachable
		// branches, and that lint should only be emitted when the feature is enabled.

Uh oh!

add unreachable_cfg_select_predicates lint #149960

Are you sure you want to change the base?

add unreachable_cfg_select_predicates lint #149960

Conversation

folkertdev commented Dec 13, 2025

Uh oh!

rustbot commented Dec 13, 2025

Uh oh!

rustbot commented Dec 13, 2025

Uh oh!

Urgau commented Dec 13, 2025

Uh oh!

folkertdev commented Dec 13, 2025

Uh oh!

traviscross commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Dec 14, 2025

Uh oh!

rustbot commented Dec 14, 2025

Uh oh!

folkertdev commented Dec 14, 2025

Uh oh!

WaffleLapkin Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

traviscross Dec 16, 2025 • 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!

WaffleLapkin Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

WaffleLapkin Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

folkertdev commented Dec 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

add `unreachable_cfg_select_predicates` lint #149960

add `unreachable_cfg_select_predicates` lint #149960

traviscross commented Dec 14, 2025 •

edited

Loading

traviscross Dec 16, 2025 •

edited

Loading