Changing `[workspace.lints.clippy]`/`[lints.clippy]` causes `cargo build` to recompile

[jalil-salame]

Problem

Changing an entry in [workspace.lints.clippy] or [lints.clippy] causes cargo build and cargo check to recompile the project since the arguments to rustc change. Ideally [workspace.lints.clippy]/[lints.clippy] would only change invocations of cargo clippy, not all cargo commands.

Steps

# Create workspace
mkdir reproducer
cd reproducer
cat > Cargo.toml <<EOF
[workspace]
members = []
resolver = "3"
EOF

# Create crate
cargo new --vcs none clippy-rebuilds

# Build to ensure the cache works
echo Fresh build
cargo build --verbose --workspace
echo Cached build
cargo build --verbose --workspace

# Add workspace lints
cat >> Cargo.toml <<EOF
[workspace.lints.clippy]
manual_string_new.level = "warn"
EOF

cat >> clippy-rebuilds/Cargo.toml <<EOF
[lints]
workspace = true
EOF

# Check that the cache fails
echo Build after inheriting lints
cargo build --verbose --workspace

Script output:

❯ bash reproducer.bash
    Creating binary (application) `clippy-rebuilds` package
      Adding `clippy-rebuilds` as member of workspace at `/tmp/reproducer`
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
Fresh build
   Compiling clippy-rebuilds v0.1.0 (/tmp/reproducer/clippy-rebuilds)
     Running `/home/ubuntu/.local/share/rustup/toolchains/1.88.0-x86_64-unknown-linux-gnu/bin/rustc --crate-name clippy_rebuilds --edition=2024 clippy-rebuilds/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=245 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=85dd4b777fcca6fe -C extra-filename=-5c7e267753dfe137 --out-dir /tmp/reproducer/target/debug/deps -C incremental=/tmp/reproducer/target/debug/incremental -L dependency=/tmp/reproducer/target/debug/deps`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
Cached build
       Fresh clippy-rebuilds v0.1.0 (/tmp/reproducer/clippy-rebuilds)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
Build after inheriting lints
       Dirty clippy-rebuilds v0.1.0 (/tmp/reproducer/clippy-rebuilds): the profile configuration changed
   Compiling clippy-rebuilds v0.1.0 (/tmp/reproducer/clippy-rebuilds)
     Running `/home/ubuntu/.local/share/rustup/toolchains/1.88.0-x86_64-unknown-linux-gnu/bin/rustc --crate-name clippy_rebuilds --edition=2024 clippy-rebuilds/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=245 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 '--warn=clippy::manual_string_new' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=85dd4b777fcca6fe -C extra-filename=-5c7e267753dfe137 --out-dir /tmp/reproducer/target/debug/deps -C incremental=/tmp/reproducer/target/debug/incremental -L dependency=/tmp/reproducer/target/debug/deps`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.24s

Possible Solution(s)

Filter [lints.*] through the tool they use, see the comment bellow #15969 (comment)

Notes

Tested with both 1.88.0 and 1.89.0.

Version

cargo 1.89.0 (c24e10642 2025-06-23)
release: 1.89.0
commit-hash: c24e1064277fe51ab72011e2612e556ac56addf7
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.5.0)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Ubuntu 22.4.0 (jammy) [64-bit]

[epage]

This came up several times during the RFC discussion:

• RFC: Add a [lints] table to Cargo.toml rfcs#3389 (comment)
• RFC: Add a [lints] table to Cargo.toml rfcs#3389 (comment)
  • This seems to be referring back to a comment from ehuss that does not come from the thread. rust-lang/rfcs@42010e8 looks to be in response to this comment as well
• RFC: Add a [lints] table to Cargo.toml rfcs#3389 (comment)
• RFC: Add a [lints] table to Cargo.toml rfcs#3389 (comment)

The RFC ended up specifying that we would filter the lints to their tool (source) to avoid fingerprinting issues though it remained an unresolved question.

In #12115, when we stabilized we settled on

We fingerprint all lints; we can optimize the fingerprinting later

and linked back to the conversation at rust-lang/rfcs#3389 (comment)

[epage]

Note, this only happens with lints.workspace = true, adding the lints directly to a crate doesn't cause this issue (to test it, remove the workspace in the reproducer)

... it shouldn't make a difference. The fingerprinting logic is the same whether you directly specify or inherit. The cost for inheriting is if you change things for one crate, all rebuild.

[jalil-salame]

Note, this only happens with lints.workspace = true, adding the lints directly to a crate doesn't cause this issue (to test it, remove the workspace in the reproducer)

... it shouldn't make a difference. The fingerprinting logic is the same whether you directly specify or inherit. The cost for inheriting is if you change things for one crate, all rebuild.

That's why I reported the bug, it does make a difference, I'll quickly reproduce the non-workspace case to show you My bad, I think my editor ran cargo clippy and it messed up my testing.

[jalil-salame]

Sorry, that was my misunderstanding, when I was testing I thought it was cached for crates, but not for workspaces, I was wrong:

# Create crate
cargo new --vcs none clippy-rebuilds
cd clippy-rebuilds

# Build to ensure the cache works
echo Fresh build
cargo build --verbose
echo Cached build
cargo build --verbose

# Add workspace lints
cat >> Cargo.toml <<EOF
[lints.clippy]
manual_string_new.level = "warn"
EOF

# Check that the cache fails
echo Build after adding lints
cargo build --verbose

Creating binary (application) `clippy-rebuilds` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
Fresh build
   Compiling clippy-rebuilds v0.1.0 (/tmp/clippy-rebuilds)
     Running `/home/jalil/.local/share/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc --crate-name clippy_rebuilds --edition=2024 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=274 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=c927668fbe8fec72 -C extra-filename=-a538169bcf60e0be --out-dir /tmp/clippy-rebuilds/target/debug/deps -C incremental=/tmp/clippy-rebuilds/target/debug/incremental -L dependency=/tmp/clippy-rebuilds/target/debug/deps`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
Cached build
       Fresh clippy-rebuilds v0.1.0 (/tmp/clippy-rebuilds)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
Build after adding lints
       Dirty clippy-rebuilds v0.1.0 (/tmp/clippy-rebuilds): the profile configuration changed
   Compiling clippy-rebuilds v0.1.0 (/tmp/clippy-rebuilds)
     Running `/home/jalil/.local/share/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc --crate-name clippy_rebuilds --edition=2024 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=274 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 '--warn=clippy::manual_string_new' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=c927668fbe8fec72 -C extra-filename=-a538169bcf60e0be --out-dir /tmp/clippy-rebuilds/target/debug/deps -C incremental=/tmp/clippy-rebuilds/target/debug/incremental -L dependency=/tmp/clippy-rebuilds/target/debug/deps`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s

[jalil-salame]

I updated the issue title/description with the information you provided. Do you think I could give this a shot? Or is it too wrapped up in the internals.

[epage]

The important thread at this point is rust-lang/rfcs#3389 (comment)

The question is how reliably can we detect that clippy is running. cargo clippy just invokes cargo check with a custom rustc driver.

We do have a couple places where we specialize behavior for clippy-driver but its only in diagnostics, not something that affects how things run

cargo/src/cargo/core/compiler/job_queue/mod.rs

Lines 1079 to 1087 in bc75590

	// To make sure the correct command is shown for `clippy` we
	// check if `RUSTC_WORKSPACE_WRAPPER` is set and pointing towards
	// `clippy-driver`.
	let clippy = std::ffi::OsStr::new("clippy-driver");
	let command = match rustc_workspace_wrapper.as_ref().and_then(|x| x.file_stem())
	{
	Some(wrapper) if wrapper == clippy => "cargo clippy --fix",
	_ => "cargo fix",
	};

cargo/src/cargo/util/diagnostic_server.rs

Lines 246 to 254 in bc75590

	fn get_bug_report_url(rustc_workspace_wrapper: &Option<PathBuf>) -> &str {
	let clippy = std::ffi::OsStr::new("clippy-driver");
	let issue_link = match rustc_workspace_wrapper.as_ref().and_then(|x| x.file_stem()) {
	Some(wrapper) if wrapper == clippy => "https://github.com/rust-lang/rust-clippy/issues",
	_ => "https://github.com/rust-lang/rust/issues",
	};
	issue_link
	}

This ends up being a policy question for what risks we are willing to take on. A prototype may help the discussion; unsure.

[jalil-salame]

Could we set a global static CALLED_CARGO_CLIPPY: AtomicBool = AtomiBool::new(false); that is set if cargo clippy was called and remove the lints otherwise as a proof of concept.

In nightly this would default to false, while in stable it would default to true, this ensures stable has the same behavior (lints.clippy is added to the fingerprinting), but in nightly you get other behavior.

My concerns are:

• Global state (easy for a PoC but doesn't scale to more lints)
• Disruptive (opt-out instead of opt-in for nightly)
• Is cargo clippy the only way people invoke clippy?

Should I add these concerns to the linked thread in the rfcs or is putting stuff here fine/better?

[epage]

I mean that cargo clippy literally spawns the process cargo check so there is no sharing to have a global track this state.

We could then have an internal-own env variable to communicate this but part of the motivation for cargo clippy being separate from cargo is to demonstrate to reaffirm that not everything has to live in cargo. Whether that is still sufficient or not or whether we should merge cargo clippy into cargo is a larger, existing conversation.

[jalil-salame]

Okay, I understand now... How about an internal CARGO_SUPPORTED_LINTS=clippy,rust,rustdoc variable? So cargo clippy sets it and cargo check picks it up?

This would make it so cargo cool could set CARGO_SUPPORTED_LINTS=cool to get its own [lints.cool] table considered for fingerprinting?

[epage]

"internal" generally means "unstable, not intended for others to use", including cool. I covered internal env variables in my earlier post.

If its not internal, our general environment variables that are not internal are actually config. This would also be getting us into the "custom tools" category which likely needs larger design work.