incompatible_msrv doesn't respect #[cfg(version(...))]

[est31]

The incompatible_msrv lint doesn't recognize that code is gated by #[cfg(version(...))], and complains about the usage anyways.

Take this code:

#![feature(cfg_version)]

pub fn maybe_pipe() {
    #[cfg(version("1.87"))]
    let _ = std::io::pipe(); // stabilized in 1.87.0
}

With this toml:

[package]
name = "cfg-version-test"
version = "0.1.0"
edition = "2024"
rust-version = "1.85.0"

[dependencies]

It will lint, even though the code is fine:

warning: current MSRV (Minimum Supported Rust Version) is `1.85.0` but this item is stable since `1.87.0`
 --> src/lib.rs:5:13
  |
5 |     let _ = std::io::pipe();
  |             ^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#incompatible_msrv
  = note: `#[warn(clippy::incompatible_msrv)]` on by default

cc rust-lang/rust#64796 #[cfg(version(...))] tracking issue

[Alexendoo]

Was planning to quickly take care of that but any()/all() complicate it a bit. Just parsing the plain cfg(version) is an option

Up for grabs for now, may take another look at it next week if nobody else does in the meanwhile

[est31]

I think as a simplification, we can treat any and all the same: traverse them and the moment we find a cfg(version) we add it. it might cause some code to not be detected by incompatible_msrv but that's better than a false positive.

As for not, I would ignore anything directly inside not, but still traverse the children for any potential reappearances of not: a version(...) there should count again, i.e. if the number of not nestings is even, count version(...), if it's not even, don't count it.

Can be done via some recursive search. We are interested in the maximum number of this whole tree I guess, and use it as the MSRV of the whole block (if it's larger than the MSRV specified in Cargo.toml, if not then we take that one).

@Alexendoo if you did a PR to check for plain cfg(version), that would help a lot already. From there, I can implement the recursive search as a followup.

[Alexendoo]

Opened #14940, handling any/etc was relatively straightforward whereas the sym::cfg_trace thing stumped me for a while

It picks the minimum version from the tree rather than maximum since that's the lowest version the code might be compiled with

[est31]

Great work, thank you! FWIW, I didn't want to make my comment above too complicated, but I think this heuristic would be better than always taking the minimum or always the maximum:

• take the minimum of the versions for any
• the maximum of the versions for all
• and flipping the roles of any and all on odd numbers of negations (de morgan rule).

[Alexendoo]

Would the lower version(s) in the maximum scenario ever be a useful cfg? If not I don't think it's worth the complexity, we could lint it even

[est31]

Is the minimum scenario useful?

Tbh I think 99% of uses will only have one version(...) inside the entire tree, either inside one not or no not at all, and probably the majority of uses will either be #[cfg(version(...))] or #[cfg(not(version(...)))]. From that point of view, your PR is entirely sufficient.

[Alexendoo]

Something like

#[cfg(any(
    version("1.100"),
    all(feature = "hashbrown", version("1.90"))
))]

could exist with further cfgs inside, there the common code would want to be under 1.90. But yeah it's not super likely