add unreachable_cfg_select_predicates lint

[folkertdev]

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]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

[rustbot]

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]

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]

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]

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]

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

[rustbot]

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]

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]

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

[folkertdev]

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

[WaffleLapkin]

What happened, how is this change related?

[folkertdev]

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]

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,
}

[folkertdev]

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]

@rustbot ready