`cargo --locked clippy` behaves differently than `cargo clippy --locked`

[embe-pw]

Problem

It seems that cargo --locked clippy is equivalent to cargo clippy (without the --locked flag) and not cargo clippy --locked, which is very confusing.

Steps

1. cargo init foo
2. cd foo
3. cargo clippy --locked fails (correctly, as there is no Cargo.lock)
4. cargo --locked clippy succeeds and creates Cargo.lock (incorrectly)

Possible Solution(s)

No response

Notes

(also checked on 2022-11-14 nightly)

Version

$ cargo version --verbose
cargo 1.65.0 (4bc8f24d3 2022-10-20)
release: 1.65.0
commit-hash: 4bc8f24d3e899462e43621aab981f6383a370365
commit-date: 2022-10-20
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: CentOS 9.0.0 [64-bit]
$ cargo +nightly version --verbose
cargo 1.67.0-nightly (16b097879 2022-11-14)
release: 1.67.0-nightly
commit-hash: 16b097879b6f117c8ae698aab054c87f26ff325e
commit-date: 2022-11-14
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: CentOS 9.0.0 [64-bit]

[weihanglo]

Look at this line, I guess--locked becomes a global flag. However, we only pass subcommand_args down to external subcommand (clippy is in fact an external subcommand). That might tell why we lost those global args. @epage is an expert of clap knows the exact behaviour.

Even we want to make it work, it still a breaking change in terms of argument parsing for external subcommands. We need to contemplate it more.

[embe-pw]

I understand that passing the arguments to the external subcommand may not be easy to do in a compatible way.
However, I'd expect at least a warning that an option is ignored.

[epage]

What git does in these situations is pass configuration set via global args to external subcommands via environment variables.

[epage]

More manifestations of this

• Support build.warnings rust-clippy#16963
• #gsoc > Project: XDG path support for rustup @ 💬

[epage]

This is more literally about cargo --global command vs cargo command --global but there is some overlap with broader config state like #10094 that we need to keep in mind. How much of Cargo's config loading should we expect commands to implement vs how much should we forward on? If we forward on a CLI flag as an env variable, are we interfering with that wider config?