`cargo clippy`: Provides confusing help on wrong usage

[Jujumba]

Summary

When passing an unexpected argument to cliippy, the "Usage" section of the output is wrong

$ cargo clippy ? 
error: unexpected argument '?' found

Usage: cargo check [OPTIONS]  # Should be `Usage: cargo clippy [OPTIONS]` I guess

For more information, try '--help'.

Reproducer

1. Open up a terminal
2. Execute cargo clippy
3. See the misconfusing help

Version

rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-pc-windows-msvc
release: 1.73.0
LLVM version: 17.0.2


cargo 1.73.0 (9c4383fb5 2023-08-26)
release: 1.73.0
commit-hash: 9c4383fb55986096b414d98125421ab87b5fd642
commit-date: 2023-08-26
host: x86_64-pc-windows-msvc
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:Schannel)
os: Windows 10.0.25967 (Windows 11 Core) [64-bit]

Additional Labels

No response

[blyxyas]

As information for solvers:
The way that Clippy works is via setting CARGO_WORKSPACE_WRAPPER to src/driver.rs and then running cargo check that. We need to intercept that middle step, probaly in src/main.rs.

[AlfredAn]

@rustbot claim

I will give this a shot.

[AlfredAn]

I think this issue is more difficult than it first appears. The problem with the solution @blyxyas proposed is that clippy would need to parse all possible arguments to cargo check in order to know whether they are valid, and print the error if not. This is not impossible, but would require adding a dependency on the main cargo crate and duplicating the contents of the cargo::commands::check::cli function, since it is defined in a binary crate that we can't depend on.

In my view a cleaner solution would be to send the name of the top-level subcommand (clippy) to cargo using an environment variable, and then modify cargo to read that variable and substitute the name in the error message. This would of course require a separate PR for cargo as well, not just for clippy.

Any thoughts on this?

[AlfredAn]

A hacky way to solve it could be to capture the stderr output from cargo and do a simple text replacement before printing it again. Maybe this is what you meant @blyxyas ?

[AlfredAn]

@rustbot release-assignment

[blyxyas]

Hi @AlfredAn, sorry for the delayed response.
I've inspected some more the output that Cargo gives us, and it would require more work than I expected either from Cargo or from clap.

I'll add the E-hard label, thanks for delving in though, and sorry for not responding earlier. If you still want to help, I'm still adding interesting high-impact issues that you may be interested in.

@rustbot label +E-hard

[Jujumba]

As information for solvers: The way that Clippy works is via setting CARGO_WORKSPACE_WRAPPER to src/driver.rs and then running cargo check that. We need to intercept that middle step, probaly in src/main.rs.

I got curious by the efforts of the previous guy, think I'll give it a try. I looked into source code and only found RUSTC_WORKSPACE_DRIVER, is that is?

Most surprisingly, I can't build the latest commit clippy of nightly toolchain, it fails to compile clippy_utils:

~/P/rust-clippy (master) $ cargo +nightly build
   Compiling clippy_utils v0.1.90 (/home/jujumba/Projects/rust-clippy/clippy_utils)
error[E0432]: unresolved imports `rustc_hir::ImplItemRef`, `rustc_hir::TraitItemRef`
  --> clippy_utils/src/paths.rs:13:17
   |
13 | use rustc_hir::{ImplItemRef, ItemKind, Node, OwnerId, TraitItemRef, UseKind};
   |                 ^^^^^^^^^^^                           ^^^^^^^^^^^^ no `TraitItemRef` in the root
   |                 |
   |                 no `ImplItemRef` in the root
   |
# snip
Some errors have detailed explanations: E0061, E0432.
For more information about an error, try `rustc --explain E0061`.
error: could not compile `clippy_utils` (lib) due to 7 previous errors

The readme of clippy_utils says that it's okay to change, but I didn't expect for it to break the master branch so suddenly. Or perhaps I'm missing something?

@blyxyas

[Jujumba]

@rustbot claim

[blyxyas]

That breakage happens because of rust-lang/rust#143357. Remove that +nightly and it should take the version pinned on rust-toolchain.toml, which is guaranteed to work (It gets updated every two weeks, so it's a pretty recent nightly)