Repository navigation
cfg_select should check for unexpected_cfgs on other arms #149090
Description
Code:
#![feature(cfg_select)]
fn main() {
let demo1 = cfg_select! {
true => "valid",
invalid_cfg1 => "invalid",
_ => "fallback"
};
let demo2 = cfg_select! {
invalid_cfg2 => "invalid",
true => "valid",
_ => "fallback"
};
dbg!(demo1, demo2);
}Output:
Compiling playground v0.0.1 (/playground)
warning: unexpected `cfg` condition name: `invalid_cfg2`
--> src/main.rs:10:9
|
10 | invalid_cfg2 => "invalid",
| ^^^^^^^^^^^^
|
= help: expected names are: `docsrs`, `feature`, and `test` and 31 more
= help: consider using a Cargo feature instead
= help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint:
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(invalid_cfg2)'] }
= help: or consider adding `println!("cargo::rustc-check-cfg=cfg(invalid_cfg2)");` to the top of the `build.rs`
= note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
= note: `#[warn(unexpected_cfgs)]` on by default
warning: `playground` (bin "playground") generated 1 warning
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.60s
Running `target/debug/playground`
[src/main.rs:14:5] demo1 = "valid"
[src/main.rs:14:5] demo2 = "valid"
Here we get a warning on invalid_cfg2 since the invalid arm for demo2 comes before the matched arm (true). Ideally we should get the same warning for invalid_cfg1 because it also isn't a valid configuration: however, since true is hit first in the demo2 case, the rest of the arms don't currently get checked.
Version: 1.93.0-nightly (2025-11-18 3d461af)
Metadata
Metadata
Assignees
Labels
Area: `cfg_select!`Area: --check-cfgArea: Messages for errors, warnings, and lintsCategory: An issue proposing an enhancement or a PR with one.Items that are on lang's radar and will need eventual work or consideration.Relevant to the compiler team, which will review and decide on the PR/issue.Relevant to the language team
Activity
JonathanBrouwer commentedon Nov 19, 2025
I think I got really close to accidentally fixing this in #148712
I'll see how easy this is to fix
@rustbot claim
tgross35 commentedon Nov 19, 2025
Cc @rust-lang/lang to make sure this makes sense. I believe it's what users would expect following the approximate mental model of
cfg_select!{ pred1 => res1, pred2 => res2 }expanding to#[cfg(pred1)] res1; #[cfg(pred2)] res2;.Urgau commentedon Nov 20, 2025
If we think of them as arms, we should examine all the arms and lint on them, regardless of whether they have been evaluated.
We already do lint in a similar situation for configs that are "not evaluated" in predicates:
cfg(any(true, invalid_cfg)).joshtriplett commentedon Nov 26, 2025
I do think it makes sense to check as much as we can, here.
At some point, we may want to evaluate to what degree we want to support people doing
cfg(all(rust_version(...), new_predicate_in_current_rust))without error. But that isn't specific tocfg_select!.joshtriplett commentedon Nov 26, 2025
We discussed this in today's @rust-lang/lang meeting.
We agreed that we should go ahead with the proposed change to apply the lint to the other arms.
Future work on short circuiting would need to be consistently applied to all/any/cfg_select/etc, and would need some further design to balance version handling with thorough checking. (For instance, being more permissive after a version check.)
Rollup merge of rust-lang#149380 - JonathanBrouwer:cfg_select_lints, …
Unrolled build for #149380
Rollup merge of #149380 - JonathanBrouwer:cfg_select_lints, r=Urgau
Rollup merge of #149380 - JonathanBrouwer:cfg_select_lints, r=Urgau
Rollup merge of #149380 - JonathanBrouwer:cfg_select_lints, r=Urgau