This saved 1.3 KiB
When color support is enabled, this likely won't save on build times
*until* `is-terminal` is removed. At that point, `bitflags` will no
longer be in our dependency tree.
I did not (yet) reproduce the `Debug` impl.
I must have been moving too fast with 6e1e754 as it changed the wrong
part of the text when really the whole thing needed an overhaul.
So this correctly fixed#4728
This is mostly targeted at reducing startup time for no-op commands
within *very* large applications, like deno (see #4774).
This comes at the cost of 1.1 KiB of binary size
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
```
Next-line help for possible values does not feel like its pulling its
weight. If anything we should do next-line help for the entire
argument.
This dropped about 0.5 KiB but more importantly is prep for other
changes.
Random fixes along the way
- In one case the space after `tip:` was "colored" (won't matter until
themeing is available)
- One error case didn't color invalid values
- Changed the args associated with invalid values to be `literal` rather
than `warning`
- Changed the required value count to be `good`
- Changed the arg for invalid value counts to be `literal` (the actual
count is `warning`)
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
One challenge with this is finding something that generally works.
Making this work perfectly for one setting will make it inconsistent
with other settings and take up more binary size / compile time.
So in the end, I felt like just mirroring rustc (with a bit more
brevity) seemed like a decent experiment. This will be evaluated by the
feedback on release.
This is a small part of #4638
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`
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
