This command cleaned up all the format args,
making code significantly shorter and more readable.
```
cargo clippy --workspace --fix -- -A clippy::all -W clippy::uninlined_format_args
```
We are doing direct transmutes between `OsStr` and `[u8]`.
https://github.com/rust-lang/rust/pull/95290 would make this natively
supported but I got tired of waitin for it.
This only saves about 1/4s off of `cargo build`.
This took 2.9 KiB off of `cargo bloat --release --example git`
zsh completions for commands that have multiple Vec arguments require
special care.
We can have two Vec args separated with a value terminator.
We can also have two Vec args with no value terminators specified
where the final arg uses 'raw' and thus requires '--' to be used.
The 2nd of these scenarios requires special handling to avoid
emitting a duplicate '*:arguments' completion entry.
Currently, the zsh completions generate an error in this scenario:
$ my-app <TAB>
_arguments:...: doubled rest argument definition:
*::second -- second set of of multi-length arguments:
We already use the '-S' option when calling _arguments.
This option makes it so that completion stops after '--' is encountered.
This means that the handling for trailing 'raw' arguments does not need
to specified.
Special-case multi-valued arguments so that we can skip emitting
the final multi-valued argument if a previous multi-valued argument
has already been emitted.
Closes#3022
Signed-off-by: David Aguilar <davvid@gmail.com>
Emit the user-defined value terminator into the zsh completion pattern
to avoid doubled rest-arguments definitions:
$ my-app <TAB>
_arguments:comparguments:325: doubled rest argument definition:
*::second -- second set of of multi-length arguments:
https://github.com/clap-rs/clap/issues/3266#issuecomment-1007901407
noted that including the value terminator is one step towards a
robust solution for handling multiple multi-valued arguments.
This change does not yet handle automatically detecting when a value
terminator is needed, but it does add tests to ensure that
user-specified value terminators are used on zsh.
Related-to: #3022
Signed-off-by: David Aguilar <davvid@gmail.com>
With the previous fixes for #4273 and #4280 in place, it's now easy to
add support for subcommand aliases, which this commit does. This
addresses #4265 for Bash.
This continues the work started with the fix for #4273. There was
another bug caused by using the subcommand names without considering
their position in the argument list. If the user enters `git diff log
<TAB>`, we build up a string that identifies the subcommand. We ended
up making the string `git__diff__log` in this case because we appended
`__log` without considering the current state. Since `git__diff__log`
does not correspond to an actual command, we wouldn't provide any
suggestions.
This commit restructures the code so we walk subcommands and
subsubcommands in `bash.rs`. While walking those, we build up a list
containing triples of the parent `$cmd` name (e.g. `git__diff`), the
current command's name (e.g. `log`), and the `$cmd` for the current
command. We then build the shell script's case arms based on that
information.
We could instead have fixed#4280 by using the second element in the
pair returned from `utils::all_subcommands()` (a stringified list of
the subcommand path) instead of the first one. However, that would not
have helped us solve #4265.
Closes#4280
Early in the Bash-completion script, we build up a string that
identifies the command or subcommand. When we see the top-level
command's name (e.g. `git`) we set the command so far to that
value. We do that regardless of where in the argument list it
appears. For example, if the argument list is `git diff git`, we set
the current command to `git` when run into it the second time. We
therefore suggest arguments to the top-level command afterwards, which
is not correct.
This patch fixes that by also considering the string that identifies
the command so far, so we only set the overall command to `git` if the
command so far is the empty string.
This is actually just a step on the way to getting completion to work
for aliases of subcommands.
Closes#4273
There seems to be little reason to return early with an empty list
when there are no subcommands, instead of going through the loop 0
times and then returning the empty list.
Originally, clap carried a lifetime parameter. When moving away from
that, we took the approach that dynamically generated strings are always
supported and `&'static str` was just an optimization.
The problem is the code size increase from this is dramatic. So we're
taking the opposite approach and making dynamic formatting opt-in under
the `string` feature flag. When deciding on an implementation, I
favored the faster one rather than the one with smaller code size since
small code size can be gotten through other means.
Before: 567.2 KiB, 15.975 µs
After: 541.1 KiB, 9.7855 µs
With `string`: 576.6 KiB, 13.016 µs
Adds parser flags to toggle whether to run the
expensive clone logic for completions case.
Help completion will only suggest subcommands, not args.
clap_complete generator sets the flag.
Another step towards #1041
This isn't the long term type for `PossibleValue::help`, I just wanted
to get the lifetime out of the way first before figuring out how help
will work.
multiple_values is now just book keeping for the builder, instead people
should look to actions and `num_args`.
The meaning for it was a little weird anyways.
The only time it won't be initialized is before `_build`. This is possible because
of #4027
I wish I could just put the `expect` inside the call but I'm worried
about allowing people to build stuff on top of clap.
We aren't enumerating arguments but values for an argument, so the name
should reflect that.
This will be important as part of #1807 when we have more specific
attribute names.
This mostly exist for
- Knowing of the value came from the command-line but we now have
`ArgMatches::source`
- Counting the number of flags but we now have `ArgAction::Count`
Inspired by argcomplete, this provides Rust-implemented completions
- Only bash for now
- No subcommand support
- No flag value support
- No special settings support
- No handling of positions within positionals
- No prioritizing of required or removing of conflicts (including
self-conflicts)
`Command::_build_all` started as an internal function for
`clap_complete` as a stopgap until #2911. Overtime, we've been finding
more cases where this function needs to be called, so now we're going to
fully embrace it until #2911 so people aren't scrared off by the hidden
implementation from using it.
This was inspired by #3602
Comptibility: Though this adds a deprecation which we general reserve
for minor or major versions, this is enough of a corner case that I'm
fine doing this in a patch release.
