Before #2005, `Clap` was a special trait that derived all clap traits it
detected were relevant (including an enum getting both `ArgEnum`,
`Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`,
`Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't
very descriptive.
This also helps further clarify the relationships so a crate providing
an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely
to choose the needed trait to derive.
Also, my proposed fix fo #2785 includes making `App` attributes almost
exclusively for `Clap`. Clarifying the names/roles will help
communicate this.
For prior discussion, see #2583
Before there was no way to make `SubcommandsNegateReqs` with
`clap_derive` because it required a required field with a sentinel value
for when the required part was negated. We blocked that.
This turned out simpler than I expected.
This came out of the discussion for #2255 but that issue is more
specifically about the panic, so not closing it.
Before, validating UTF-8 was all-or-nothing and would cause a `panic` if
someone used the right API with non-UTF-8 input.
Now, all arguments are validated for UTF-8, unless opted-out. This
ensures a non-panicing path forward at the cost of people using the
builder API that previously did `value_of_os` need to now set this flag.
Fixes#751
Right now
- `default_value="something"` is a raw method
- `default_value` uses native types
This commit splits the meanings
- `default_value="something"` is a raw method
- `default_value_t` uses `T::default()`
- `default_value_t=expr` uses an expression that evaluates to `T`
This is meant to mirror the `value_of` / `value_of_t` API.
At the moment, this is limited to `T: Display` to work with clap's
default system. Something we can look at in the future is a way to
loosen that restriction. One quick win is to specialize when `arg_enum`
is set. The main downside is complicating the processing of attributes
because it then means we need some processed before others.
Since this builds on `clap`s existing default system, this also means
users do not get any performance gains out of using `default_value_t`,
since we still need to parse it but we also need to convert it to a
string.
Fixes#1694
It looks like CI hasn't been running on this and we've introduced some
problems. It looks like we had an off-by-one error in the check for
MSRV for deciding to run ui tests.
