epage
commented
1 year ago Except in some specific cases (#3912, #3864), the derive API handles all of this for you at compile-time
When using ArgMatches::get_*, we will panic at runtime. This just requires exercising all ArgMatches::get_* calls in tests and you know things are valid. You could use try_get_one::<CustomToolchainNameParser as TypedValueParser>::Value>("toolchain") to help (if those were even the right types and args involved, I also don't know if you can shorten that for associated value accesses)
Instead of either of the above, rustup is using ArgMatches::try_get_* and its unclear from the Issue what rustup does in the case ofErr(MatchesError::Downcast {...} }).
I'm not too sure what more clap can do to help in this case or how the docs could be modified to help people who have explicitly chosen to go off the beaten path and then (making assumptions here) ignoring the error we are reporting about this case.
rbtcollins
Please complete the following tasks
Clap Version
3.2.23
Describe your use case
Trying to parse
toolchainarguments forrustupas a custom type rather than just String. We have about 5 different sorts of toolchains that can be parsed. Official ones from channels, custom names, official-or-custom, 'none'-or-official-or-custom.When the clap value parser type (e.g. CustomToolchainNameParser) and the code querying the argument have a mismatched type, there is a silent failure (or perhaps we're misusing things?)
e.g. in the install code path I had this:
and the definition for install has this :
Then the type id check in
verify_arg_tfails, but this is then caught intry_get_many- which I think we're using to handle optional values. But this is a different sort of failure - the failure is in the code that was compiled, and should be detectable at compile time.Describe the solution you'd like
Our buggy code should fail to compile. Or perhaps we're doing things wrong and the docs should help us understand that.
Alternatives, if applicable
No response
Additional Context
No response