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]

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