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.
These didn't make sense for the builder but are helpful for the derive.
The assert was assuming people wouldn't do this and to catch internal
problems.
Fixes#4326
This originally stemmed from wrapping `Arg` in a `Box`, but we had to
smash it with a hammer as it didn't improve things enough.
- This dropped binary size by 3-7 KiB
- Parsing slowed by 20%.
- Incremental rebuilds slowed down by 1%
The styling of usage has changed in #4188 such that the usage string is on
the same line as the "Usage:" title. Previously, the usage went on the line
below the title. As such, the rules have changed for how to make a
multiline usage format correctly.
These updated rules achieve the following output for the documented
example:
Usage: myapp -X [-a] [-b] <file>
myapp -Y [-c] <file1> <file2>
myapp -Z [-d|-e]
Relates-to: #4132
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 gives users the control over where clap outputs while still getting
colors. For users who want to support old windows versions, check out
`fwdansi` crate.
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
Things that tripped up a user
- Derive reference was misunderstood to say that the only alternative to
the built-in value parser behavior was to implement
`ValueParserFactory`
- We now delegate to `value_parser!`s docs any talk of integrating
into it (it should have been a subbullet of "not present" anyways)
- `value_parser!` relies too much on the example to demonstrate behavior
when the user will likely make the determination of whether its
relevant before then
- We are now more upfront what type mappings are supported
- Too many steps to find all information
- For example, a user needs to look at `TypedValueParser`
implementations, `ValueParserFactory` implementations, and `From<T>
for ValueParser` implementations to understand what all can be used
- We are now more upfront with a lot of this information at the entry
points the user is most likely to look at
In addition, I did an audit of the docs to make sure they were updated
for us only supporting the new behavior and all of the new APIs.
See https://www.reddit.com/r/rust/comments/xjlie4/preannouncing_clap_40_a_rust_cli_argument_parser/ip9kzf1/
`clap::Error::raw` was producing ambiguity errors with a default generic
parameter on `clap::error::Error` (which `clap::Error` is a re-export
of).
I tried making `clap::Error` a type alias with a default generic
parameter but that ran into an ambiguity error with `map_err`.
So I'm going ahead and hard coding `clap::Error`. We don't expect
people to change this all that often.
This takes off another 14 KiB when color us not used. My hope is that
we'll be able to switch away from `termcolor` to a term styling crate
that will make this work in the color case as well.
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 overall hope is to allow a `&'static str`-only version of clap, so
we need to move off of `Str` where dynamic strings are required. We
need it here for subcommands due to external subcommands.
This had minimal impact on code size (567.2 to 567.5 KiB)
This makes us accept `str` and not do any allocations at the cost of
panicing if unsupported which I think fits our overall story in trying
to catch development-time errors.
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
This was ported over from the usage parser which modeled after docopt.
We just never got around to implementing the rest of the syntax.
However, when considering this as a standalone feature, an
`arg!(--flag <value>)`, outside of other context, should be optional.
This is how the help would display it.
Fixes#4206
