This is a cheap pass at creating this to allow cutting out the cost of
rich error information / programmatic error information.
This cuts about 20 KiB off of the binary.
There is more we could cut out, like collecting of used arguments for
the usage, but I want to keep the conditionals simple.
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
`multicall` allows you to have one binary expose itself as multiple
programs, like busybox does. This also works well for user clap for
parsing REPLs.
Fixes#2861
This creates distinct tutorial examples from complex feature examples
(more how-tos). Both sets are getting builder / derive versions (at
least the critical ones).
This ports our example testing over to [trycmd](https://docs.rs/) so
we can:
- More thoroughly test our examples
- Provide always-up-to-date example usage
The old way of testing automatically picked up examples. This new way
requires we have a `.md` file that uses the example in some way.
Notes:
- Moved overall example description to the `.md` file
- I added cross-linking between related examples
- `14_groups` had a redundant paragraph (twice talked about "one and
only one"
Because we gradually build the `ArgGroup` as we parse the YAML, we don't
use `ArgGroup::new`. Clap3 introduced an internal `id` in addition to
the public `name` and it appears that this custom initialization code
was not updated.
This shows the problem with publically exposing `impl Default`.
Choices:
- Remove `impl Default`
- Always valid
- Requires spreading invariants
- Callers can't implement code the same way we do
- Add `ArgGroup::name`
- Can be constructed in an invalid state
- Centralizes invariants
- A caller could implement code like the yaml logic
I decided to go with `ArgGroup::name`.
Fixes#2719
