There are other cases for `required` that aren't being handled
- Groups
- Conflicts
I'm concerned there might be weird corner cases and didn't want the
analysis for that to block fixing this.
Fixes#5507
Inspired by rust-lang/cargo#12494.
Part of this is that our "did you mean" does prefix checks so it can be
overly aggressive in providing suggestions.
To avoid providing needless suggestions I limited this change to `last`
/ `trailing_var_arg` as those convey that `--` is more likely a valid
suggestion.
With #5298, I had overlooked that `matcher.arg_ids()` includes
`ArgGroup`s. I had assumed I could always find a present `id` among
`Arg`s and `unwrap`ed.
I skipped a test for this because the use case is a bit strange that the
long term value for the test would likely be low.
If/when we add derive support for `args_conflicts_with_subcommands`, it
will then cover this case.
Fixes#5304
In some sophisticated situations, these may be expensive to calculate.
One example might be a '--branch' option accepting any single Git
branch that exists on the remote -- in such a case, the remote would
need to be queried for all possible_values. The cost is ultimately
unavoidable at runtime since this validation has to happen eventually,
but there's no need to pay it when generating help text if
`is_hide_possible_values_set`.
To keep '-h' fast, avoid collecting `possible_values` during '-h'
unless we're actually going to use the values in display.
This optimization is repeated for the manpage renderer.
This is trivially based on the short-circuiting logic at [1], which at
least supports the idea that actually consuming the iterator is not
generally-guaranteed behavior when `hide_possible_values` is set.
Note on the 'expensive' mod: This keeps all the possible_values tests
in one file but allows the entire set of tests to be controlled by the
'strings' feature (which is required to be able to use String rather
than str for each possible value).
[1]: clap_builder/src/builder/command.rs:long_help_exists_
