-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
infer_subcommands should not fail if the ambiguity is over aliases #5021
Comments
#4815 has some more information on this though that was covering multiple issues with inferring, so I've closed it out for one specific one, pointing here. |
Won't be able to do research anytime soon, but if it's decided that this issue should be fixed, I can put up my PR. |
When there is ambiguity between a subcommand and its alias, it would be an error today. Turning error cases into success is not a breaking change. We have three different inference checks
(based on code inspection and experimentation in #4815) So resolving this would resolve an inconsistency. Deciding on the consistency to error (prefer subcommand names approach) would likely be considered a breaking change. It is also an overall lesser user experience. The only reason we may consider it is if we felt it would offer enough binary size savings that we weigh that out over the impact of people affected by this behavior. I have a hard time seeing how this would make a significant difference in binary size; many similar size changes go in without being measured. So from that, I'd be willing to merge a fix for this. I would ask that the fix ensure that tests exist for subcommand longs and longs, adding them if they don't. A nice to have is to have the first commit add the test, verifying the existing behavior (error) and the second commit fixes the bug and updates the test. This helps show confirm to reviewers (1) the test is testing the right thing and (2) the change has the intended afect. |
* Add env feature to clap and cargo update * Dead Code: WIP CLI changes * Dead Code: CLI feature parity Although see clap-rs/clap#5020 * Note about not (yet) using infer_subcommands See clap-rs/clap#5021 * Use clap/wrap_help Although see clap-rs/clap#5022 * WIP: Strip out previous CLI argument parser setup [skip ci] * WIP: Normalise arguments for caller [skip ci] * Don't check for file-ness in the CLI argument parser * File and directory canonicalisation for the argument parser * Expose CLI types so they can be used downstream
* Add env feature to clap and cargo update * Dead Code: WIP CLI changes * Dead Code: CLI feature parity Although see clap-rs/clap#5020 * Note about not (yet) using infer_subcommands See clap-rs/clap#5021 * Use clap/wrap_help Although see clap-rs/clap#5022 * WIP: Strip out previous CLI argument parser setup [skip ci] * WIP: Normalise arguments for caller [skip ci] * Don't check for file-ness in the CLI argument parser * File and directory canonicalisation for the argument parser * Expose CLI types so they can be used downstream
Please complete the following tasks
Rust Version
rustc 1.70.0 (90c541806 2023-05-31) (built from a source tarball)
Clap Version
4.3.12
Minimal reproducible code
Steps to reproduce the bug with the above code
Actual Behaviour
It recognises the ambiguity between
config
andcfg
:Expected Behaviour
When an ambiguity only spans a single subcommand and its aliases, then it should resolve to that subcommand:
Additional Context
infer_long_args
may also have the same behaviour; I haven't checked.Debug Output
The text was updated successfully, but these errors were encountered: