non_minimal_cfg suppression sometimes not effective

[ijackson]

Summary

Putting #![allow(clippy::non_minimal_cfg)] at the top of the module, or on the mod statement, sometimes doesn't work!

Lint Name

non_minimal_cfg

To reproduce

Cargo toml

[package]
name = "test"
version = "0.0.1"
edition = "2021"
publish = false

[features]
recent = []

src/lib.rs

mod middle;

src/middle.rs

#![allow(clippy::non_minimal_cfg)]

#[cfg(all(
    feature = "recent", // we want toml parser etc.
))]
mod inner;

src/middle/inner.rs

empty.

Or from git:

git clone https://gitlab.torproject.org/Diziet/rust-derive-deftly -b clippy-non-minmal-cfg-bug-repro
cd rust-derive-deftly
cargo  clippy --all-features

Actual output

    Checking test v0.0.1 (/volatile/rustcargo/d/rust-derive-deftly)
warning: unneeded sub `cfg` when there is only one condition
 --> src/middle.rs:3:7
  |
3 |   #[cfg(all(
  |  _______^
4 | |     feature = "recent", // we want toml parser etc.
5 | | ))]
  | |_^ help: try: `feature = "recent"`
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#non_minimal_cfg
  = note: `#[warn(clippy::non_minimal_cfg)]` on by default

warning: `test` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s

Expected output

No lint output.

Version

rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-linux-gnu
release: 1.79.0
LLVM version: 18.1.7

Also fails with current beta and nightly.

Notes

Moving the #![allow()] to an #[allow()] on mod middle doesn't help. Changing it to #[allow] to apply only to mod inner, makes the bug go away.

Bizarrely, changing mod inner; to mod inner {} makes the bug go away too!

In my actual project I'm using #![allow(clippy::complexity)] at the crate top-level.

[y21]

I think this is the general, known issue that every pre-expansion lint pass runs into unfortunately... cc #12538 #7549 #5721 #6610 and probably a lot more

This lint could perhaps be rewritten as a normal post-expansion lint pass, but it would then no longer be able to lint cfgs that are false for the current compiler session

[ijackson]

This lint could perhaps be rewritten as a normal post-expansion lint pass, but it would then no longer be able to lint cfgs that are false for the current compiler session

I think this means there needs to be a pre-expansion pass to look for #[allow]s.

[ijackson]

Also, it would have saved me the effort of filing this report, if the situation were documented. I think this would have to be a note in the docs for every pre-expansion lint.