We prefer Settings to always be off by default, so when we change a
default, we have to rename.
This adds back in the now-default settings with deprecation messages to
help the user know how things now work.
Unfortunately, there is no way to notify the user that the default they
relied on has changed. This also doesn't help us when the change in
behavior is more than just an inverting, like `InvalidUtf8` or when a
setting mapped to multiple bits.
This partiall reverts commit efeb02cd34,
bringing back the `AppSettins::Color*` and making them the backing store
for `App::color`, to help ease the transition from clap2->3.
Once we remove these deprecated settings, we might want to keep this
backing store to save on memory.
This is a part of #2617
This brings back the old name of settings, just deprecated. Since they
all map to the same bits in the bit field, this should work for
`setting` and `is_set`. The only thing this lacks is being able to do
equality across variants, whcih seems like a minority case.
Removed settings have some extra care abouts that we'll need to look
into separately.
This is a part of #2617
When an anonymous struct is inside of an enum, we end up applying the
App methods twice, once for the `augment_args` and once for variant.
This consolidates those calls.
Fixes#2898
2926: Put `grouped_values_of` behind a feature gate r=pksunkara a=epage
2948: docs(generate): Move derive example to generate r=pksunkara a=epage
Co-authored-by: Ed Page <eopage@gmail.com>
From a users perspective, `clap_derive` is baked into `clap`.
`clap_generate is an add on to `clap`. So it seems best to have all
`clap_generate` examples in `clap_generate` where a user will look for
them.
Fixes#2939
If the user prints a raw error, it may include color even if the user
turned it off at runtime. Now we'll be more conservative and never show
color for raw errors.
While `App::error` is what most people will need, `clap_derive` needs to
handle when the site raising the error doesn't have access to the `App`
and needs to defer that to later.
Due to a copy/paste bug, we were reading the `help_heading` for
Subcommands from the enum's attribute and not the variant's attribute.
It doesn't make sense for the outer command's help_heading to control
the subcommands help_heading.
This does raise an interesting question on inheriting / propagating help_heading,
which I originally wrote the tests for. We'd first need to answer
whether it should be built-in to the builder or derive-specific.
In working on converting unwraps to errors, I noticed that we did not
spport `arg_enum` for `Option<Option<_>>` and `Option<Vec<_>>`, so this
addresses that.
My main motivation was to consolidate and make the logic more
consistent, the bug fix just fell out of that work.
This is meant to lower the chance of confusion with cases like #2714 and #1586.
This is not meant to be exhaustive, looked at the mentioned cases in
that issue and pattern matched on other ones mentioning "is present".
When I'm making changes, I frequently have to touch every error
function. This creates a more standard builder API so we can more
easily add or modify fields without having to update every case.
PR #2751 highlighted a problem we have where the variable names we use
could collide with users. Rather than parse out when or not to use
special names, and worry about people keeping that up to date through
refactors, I globally renamed all variables by adding a `__clap_`
prefix, which looks like what serde does to solve this problem.
I audited the result with `cargo expand`. I didn't add any tests
because any tests would be reactionary and would give us a false sense
of protection since any new code could hit this with anything we do.
Our best route for naming is consistency so people are likely to notice
and copy.
Fixes#2934
