Cargo should give helpful errors when unsupported flags are used.

Problem

There are several flags one might imagine users passing to Cargo that aren't supported yet. It'd be nice if we told users who try to use these what to use instead, and perhaps also linked to the issue (if any) proposing to add such a flag. Some examples:

There's no -C for running in a different directory. (blocked on cargo -C dir does not use the rust-toolchain.toml file within the given directory. #11957)
There's no -w or -W short for --workspace (except in update, blocked on Add short flag -w for --workspace #11554).
There's no -x for --exclude Add unsupported short flag suggestion for --target and --exclude flags #12805
There's no -t for --target Add unsupported short flag suggestion for --target and --exclude flags #12805
There's no -s for --quiet (-s is "silent" in curl) Add better suggestion for the unsupported silent flag #12723
It's --manifest-path, not --path (though there is --path for cargo add)
There's no -c for --config Add test for unsupported short config flag #12777
There's no -z, only -Z Add unsupported lowercase -z flag suggestion for -Z flag #12788
There's no -O, only --out-dir Add unsupported short suggestion for --out-dir flag #12755
There's no -n for --dry-run feat(cli): Add '-n' to dry-run #12660

Proposed Solution

No response

Notes

No response

Does it make sense having this as a built-in mechanism in clap for suggesting an alternative flag?

@weihanglo

@weihanglo I think that can make sense to seed clap with specific suggestions and not just rely on the automatic suggestions and that would help simplify things for application, like cargo. Mind opening an issue?

More examples:

There's no --debug for cargo build. Only --release.
There's no --release for cargo install. Only --debug.

These does confuse people a lot. See #12009.

@rustbot

I am not sure if we should wait for upstream fix or make our own custom suggestion. Let's label it as waiting for upstream first. We still seek ad-hoc solutions if somebody is interested in.

@rustbot label +S-blocked-external

@rustbot

clap-rs/clap#5075 just got landed with clap@4.3.22. People, we now can have basic suggestions for unsupported arguments!

I'll write down a list of flags of interest and instructions shortly.

@rustbot label -S-blocked-external +S-accepted +E-easy

@rustbot

Not sure if this is the relevant clap issue clap-rs/clap#4853. Supposed we are going to leverage UnknownArgumentValueParser for those well-known unknown arguments, it might cause unwanted typo suggestion for them.

Let me label it blocked on that issue at this moment.

@rustbot label -S-accepted +S-blocked-external

@weihanglo

@weihanglo could you give an example of where that causes a problem worth blocking this issue?

Something like this? Though for short aliases clap doesn't suggest them I feel like. If that's the case we can continue working on short aliases part.

    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/cargo install --please`
error: unexpected argument '--please' found

  tip: a similar argument exists: '--release'

Usage: cargo install --release [crate]...

For more information, try '--help'.

Asking to better characterize the problem: is that always bad though?

Take the prior work in #12529, like cargo test --keep-going. If the user thought it should work and did cargo test --keep-goign, today they would get a correction and then be pointed to the correct flag (yes, ideally the two steps would be one step which might be a consideration where suggest_arg is appropriate). With the proposed change, the user would just get an unexpected argument error and would fall back to --help. Trying to understand which path is best.

@rustbot

It's not inherently bad, and agree with that two steps is better than infinite steps searching in --help. Just it is lying that “a similar argument exists”, which doesn't.

I am convinced that it's not really a blocker 😆. Would be great if clap can improve the situation.

@rustbot label +S-accepted -S-blocked-external

@rustbot

@rustbot claim

Navigation Menu

Repository navigation

Cargo should give helpful errors when unsupported flags are used. #11702

Problem

Proposed Solution

Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cargo should give helpful errors when unsupported flags are used. #11702

Description

Problem

Proposed Solution

Notes

Activity

weihanglo commented on Feb 13, 2023

epage commented on Feb 13, 2023

weihanglo commented on Apr 21, 2023

weihanglo commented on Apr 21, 2023

weihanglo commented on Aug 17, 2023

weihanglo commented on Aug 22, 2023

epage commented on Aug 22, 2023

weihanglo commented on Aug 22, 2023

epage commented on Aug 23, 2023

weihanglo commented on Aug 23, 2023

0xPoe commented on Sep 19, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions