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
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
This is an intermediate solution for #4408. As there were no agreeed
upon goals, I went with what I felt read well and that I saw commonly
used on non-clap commands.
- "information" isn't really a necessary word.
- I originally favored `Print this help` but realied that doesn't read
correctly in completions.
- Besides being shorter, the reason for the flipped short/long hint is
it gives people the context they need for scanning, emphasizing
"summary" and "more".
Fixes#4409
When overriding other fields, help or version flag, globals, etc, a user
might not care about the value, so let's ignore the lookup.
Been talking about this for a while but Issue #4367 moved this forward
because there wasn't a good way to handle this without changing
behavior.
The writer is less convenient and isn't offering any performance
benefits of avoidign the extra allocations, so let's render instead.
This supersedes #3874Fixes#3873
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, I saw the ideal as the parent command being isolated from
`#[clap(flatte)]` especially after all of the doc comment
leakage issues. We scaled that back to just `next_help_heading` because
of the issues with settling on a policy and maintenance to cover
everything. When doing `next_display_order`, we decided it would mess
things up too much to isolate it.
With #1807, we instead have been moving towards setting
`#[command(next_help_heading)]` anywhere, we just need to finish working
out how it should work.
Just having `--help` or `--version` can make us get invalid args instead
of invalid subcommands. It doesn't make sense to do this unless
positionals are used. Even then it might not make sense but this is at
least a step in the right direction.
Unsure how I feel about this being backported to clap 3. It most likely
would be fine?
This was noticed while looking into #4218
Since the `name` is changed to be the package name, we can't use it as
(1) its not as predictable and (2) it can lead to conflicts if a
`Parser` is flattened into a `Parser`
In looking at other help output, I noticed that they use two spaces, in
place of clap's 4, and it doesn't suffer from legibility. If it
doesn't make the output worse, let's go ahead and make it as dense so we
fit more content on the screen.
This is a part of #4132
The builder function was deprecated in v3 and removed in v4 but the
derive masked that, so we're still adapting things but now with a path
towards removal.
