`cargo fmt --all` from excluded sub-directory still checks parent workspace

[dhardy]

Problem

Here I run tests on an exclude-d sub-directory, benches. CI kept failing until I removed the --all from cargo fmt due to issues with other workspace members, which should not be checked from here.

Cargo.toml looks like this:

[workspace]
members = [
    "rand_jitter",
    "rand_isaac",
    "rand_xorshift",
    "rand_xoshiro",
    "rand_hc",
]
exclude = [
    "benches",
]
resolver = "2"

Therefore, cargo test -p benches from the repo root fails (expected).

However, this succeeds:

$ cd benches/
$ cargo test -p rand_hc
   Compiling libc v0.2.155

This should fail since benches is, by explicit exclusion, not part of the parent workspace.

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

No response

[newpavlov]

@weihanglo
It's not only about cargo fmt, you also can run tests (e.g. cargo test -p rand_core) for packages in root workspace from an excluded crate directory. Adding [workspace] members = ["."] to excluded crates does not help.

[weihanglo]

cargo fmt is actually an external subcommand implemented in rust-lang/rustfmt repository. It has different behavior than --all in other built-in commands Cargo.
(note that --all is dep created and we favor --workspace).

Here is the current implementation of cargo fmt --all. And here is a prior discussion you might be interested.

Given this is a thing managed by the Rustfmt team an issue in Cargo, please find an existing issue and reach out to them for further discussions.

[weihanglo]

@newpavlov Sorry I overlooked that, though that is also an expected behavior.

For the cargo test case, it is because rand_hc is a dependency of the benches package, so what cargo test -p rand_hc actually does is selecting rand_hc to test against. The same behavior applies to most build commands.

https://github.com/rust-random/rngs/blob/061af2943f51207746917ea7d6d1d422e7eb9afc/benches/Cargo.toml#L17

[dhardy]

Thanks for the explanations @weihanglo.

So I can cd rand_distr then do cargo test -p num-traits for example, running tests on Cargo's cached copy of num-traits. I hadn't expected this to work and it contributed to the confusion above, but otherwise this is likely unimportant.

Given the linked rustfmt issue, it sounds like they are uninterested in being compliant with the behaviour of other Cargo commands, so I guess this issue can be closed now.

[weihanglo]

Thanks for the understanding. Closing.