This is another step for trying to improve the understanding that the
derive and builder APIs are linked (#4090).
This also adds links to make it easier to discover more details on how
we infer behavior from a field's type.
This has been implemented for 3 years without much traction for
finishing it up.
The subcommand use case can be worked around by creating `Command`s that
just include the relevant logic, very similar to the default subcommand
examples in `git` / `git-derive`.
Using this for flags is covered by #4793.
Without `unstable-replace` being enabled, this still cut 5 KiB from
`cargo bloat --release --example git`.
Closes#2836Closes#2011
For now, we are still treating `clap` as the user facing API for both
builder and derive, making this an internal change as we don't expect
this to negatively impact builder build times all that much. We can
re-evaluate at a later time and consider having distinct top-level
crates for builder and derive.
Looking at `--timings` on my machine
- `clap` only took 0.04s to build and it happened in
parallel to `clap_builder` codegen
- this saved 1.7s for derive build times, with `clap_builder` building
in parallel to `syn` and `clap_builder` and `clap_derive` finishing
around the same time.
This was discussed some at https://rust-lang.zulipchat.com/#narrow/stream/220302-wg-cli/topic/clap.20build.20times.20and.20.60clap_derive.60.3A.20a.20crazy.20idea
We were accidentally showing long help just because a hidden argument had a description for a possible value. This is most likely to be hit with the derive API as the value descriptions are automatically applied from documentation.
Since `Inner::into_string` already takes ownership of `self` we can
avoid unnecessary copy and allocation by moving `Box<str>` and using
its implementation of `Into<String>`.
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
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.
