To "append" calls, we were passing in a more and more complex expression
on each recursive invocation. We now pass in a fixed amount of data on
each iteration, reducing how much the macro machinery needs to parse,
speeding up builds.
Fresh builds went from 39s to 32s on my machine.
Inspired by #4670
Implementation of Jaro-Winkler similarity in the dguo/strsim-rs crate
is wrong, causing strings with common prefix >=10
to all be considered perfect matches
Using Jaro instead from the same crate fixes this issue
Benefit of favoring long prefixes exists for matching common names
But not for typo detection
Hence use of Jaro instead of Jaro-Winkler is acceptable
Confidence threshold adjusted so that `bar` is still suggested for `baz`
since Jaro is strictly < Jaro-Winkler
such an adjustment is expected. This is acceptable.
While exact suggestions may change, the net change will be positive
Suggestions are purely decorative and should thus not breaking change
Fixes#4660
Also see https://github.com/dguo/strsim-rs/issues/53
derive arguments like this:
#[arg(long)]
pub flag: bool,
were producing option descriptions like this:
--flag=FLAG
FLAG is spurious. It turns out that derive always sets a value name, for
simplicity, even when there are no arguments. Check for this case.
Fixes#4443.
Adding "found" might seem minor but I feel it has a slight softening on the message. It also maintains scanability as it is at the end and short.
As this is a one-off message change and not a styling issue to be consistent with, I think this is safe to put in a patch release.
This let's you get an arguments values, grouped by the occurrence of the
argument.
Note: this does not stablize derive support. That requires a blocking
change and can be enabled via `unstable-v5` flag. See #4626 for an
exploration of how we can make this easier in the future.
Fixes#2924
My guess is this was left over from switching to using the type based
API. The generated code for extracting values from `ArgMatches` had some
code that didn't actually do anything, like mapping over the identity
function, and wrapping a value in an `Ok` only to immediately use "?" on
it.
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>
