`cargo clippy --fix` builds too many packages in a workspace (since `nightly-2025-06-01`)

[devjgm]

Problem

Since nightly-2025-06-01, a command like cargo clippy --manifest-path foo/Cargo.toml --fix where "foo" is in a workspace, the --fix option will cause all workspace members to be built, not just the one package that was specified by the --manifest-path.

Example

Using this repo https://github.com/devjgm/bug-cargo-clippy-fix-repro with two foo and bar members that were both created with cargo new, we see the following output.

❯ cargo clippy --manifest-path foo/Cargo.toml --fix
    Checking foo v0.1.0 (/private/tmp/bug-cargo-clippy-fix-repro/foo)
    Checking bar v0.1.0 (/private/tmp/bug-cargo-clippy-fix-repro/bar)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.28s

Note that I've specified --manifest-path foo/Cargo.toml, so I do not expect bar to be built, but we see that bar is also built.

• The problem goes away you remove --fix
• The problems goes away if you roll back to nightly-2025-05-31
• If I specify -p foo, the problem also goes away. However, -p should likely not be required if I've already specified --manifest-path.

I believe the issue started in 778ff68. cc @ehuss

Steps

1. cd /tmp && git clone https://github.com/devjgm/bug-cargo-clippy-fix-repro
2. cargo clippy --manifest-path foo/Cargo.toml --fix

Problem: You see that bar is also built, but it should not be.

Possible Solution(s)

I believe the problem was introduced in 778ff68

Notes

No response

Version

❯ cargo version --verbose
cargo 1.89.0-nightly (64a124607 2025-05-30)
release: 1.89.0-nightly
commit-hash: 64a12460708cf146e16cc61f28aba5dc2463bbb4
commit-date: 2025-05-30
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.7.1 (sys:0.4.80+curl-8.12.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Mac OS 15.4.1 [64-bit]

[weihanglo]

Yeah 778ff68 introduced the regression, the ws.current_manifest is not preserved after reloading with ws.root_manifest. Change this line to self.current_manifest should fix it.

@rustbot label +S-accepted +E-easy

[lemorage]

Hi, as per my understanding, this happens cuz current reload implementation only looks out for root_manifest, but leaves current_manifest alone. Can I make a PR for this if applicable?

[weihanglo]

@lemorage no problem!

[epage]

As a recommendation, we recommend splitting PRs into at least two commits:

• Adding the test with it passing, showing the bug
• Adding the fix and updating the test to pass again, so the diff shows how behavior changed