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
The regular expression for the release date update is taken from the
GitHub Action `kevinmatthes/cff-release-today@v0.5.2` which uses this
one, too. License issues should not arise as I am the author of that
GitHub Action.
The regular expression for the version update is designed to also work
with version parts consisting of multiple digits. It was tested
successfully with the example versions `1.2.3` and `1.2.30` in
CITATION.cff.
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
Fixes#4510
Note: `terminal_size` is using old version of rustix and this causes a bit dependency duplication.
Will check to bump upstream. EDIT: Someone already did - https://github.com/eminence/terminal-size/pull/46 (needs a release)
If users don't want `wrap_help` feature, they can put newlines in where
needed. Seems odd to support wrapping when the wrap size is fixed. For
those hard coding the lines, this will save them a decent amount of
size.
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
The immediate benefit is binary size but this also makes us more
flexible on the implementation, like allowing wrapping of `StyledStr`.
This removed 12 KiB from `.text`
This helps towards #1365 and probably #2037
The binary size and performance difference is enough to make it
configurable.
Code size:
- default: 565.7 KiB
- perf: 578.5 KiB
Build time:
- default: 9.1706 us
- perf: 7.0479 us
Parse time:
- default: 12.673 us
- perf: 8.1708 us
Parse with subcommand time:
- default: 12.112 us
- perf: 7.9874 us
This dropped 17KB
Again, performance shouldn't be too bad as the total number of argument
id's passed in by the user shouldn't be huge, with the upper end being
5-15 except for in extreme cases like rustc accepting arguments from
cargo via a file.
The main goal is to reduce the risk of people developing on the wrong
release, assuming they are using something like starship to raise the
visibility of the crate version.
This adds a new `Cargo.toml` feature named `deprecated` that opts
controls whether deprecation warnings show up. This is starting off as
non-default though that may change (see below).
Benefits
- Allows a staged rollout so a smaller subset of users see new
deprecations and can report their experience with them before everyone
sees them. For example, this reduces the number of people who have to
deal with #3822.
- This allows people to defer responding to each new batch of
deprecations and instead do it at once. This means we should
reconsider #3616.
The one risk is people who don't follow blog posts and guides having a
harder time upgrading to the next breaking release without the warnings
on by default. For these users, we reserve the right to make the
`deprecated` feature `default`. This is most likely to happen in a
minor release that is released in conjunction with the next major
release (e.g. when releasing 4.0.0, we release a 3.3.0 that enables
deprecations by default). By using a feature, users can still disable
this if they want.
Thanks @joshtriplett for the idea
Though this is changing an API item we export, we do not consider this a
breaking change because
- This was an implementation detail of the macros and people shouldn't be using it directly
- The `macro_rules` macro is coupled to `clap` because they are in the
same crate
- The derive macro is coupled to `clap` because `clap` declares a
`=x.y.z` dependency on `clap_derive
Fixes#3828
