A lot of users expected `color` feature flag and `ColorAuto` etc to
control all colors. Having this extra flag around is easy to miss and
adds to our overall settings bloat, making it harder to find settings
people want.
This completely removes it, rather than make it deprecated like
functions in #2617, because there is extra work to mark things
deprecated as Settings and we should decide on our strategy first before
investing time in addressing that issue.
Fixes#2806
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
This commit removes `AppSettings::DisableVersionForSubcommand` as it's
now a moot setting with clap's default functionality of not building a
version flag unless there actually exists version information.
`clap_up` must still be changed to remove this variant instead of the
current configuration to simply rename the variant.
This commit adds several debug asserts that ensure the user has not
accidentally generated a version flag that has no information. The
exception to this case is when the user wants to generate a version
flag, but then handle the version display manually. I.e. one can still
generate a "meaningless" version flag, but use
`AppSettings::NoAutoVersion` which is allowed.
Since these tie in closely with the new default behavior of not
auto-generating the `-V/--version` flags when no information has been provided they are now documented.
This commit changes the default behavior of clap to no longer generate a
`-V, --version` flag when no version information has been provided.
Version information can be provided via `App::version`,
`App::long_version`, or via `App::mut_arg("version", |_| ..)`. Using any
of the above is the only way to have clap auto-generate the version flag.
Technically, clap still generates a version flag, however it is removed
prior to parsing if the user has not provided any version information
via one of the mentioned methods.
Relates to [#2812](https://github.com/clap-rs/clap/issues/2812)
This is gated behind the `debug` feature flag so only explicit debugging
cases pay the build time and runtime costs.
The builder API's stack traces are generally not too interesting. Where
this really helps is with `clap_derive`. We currently panic on
unexpected conditions which at least gives us a backtrace. We'd like to
turn these into errors but to do so would lose those debuggin
backtraces, which is where this comes in.
This is a part of #2255
* Check for `DisableHelpFlag` along with `NoAutoHelp`
Also applies for `DisableHelpSubcommand` and `DisableVersionFlag` with `NoAutoVersion`
* Add tests for overriding help and version, and disabling version.
These override by disabling the default and adding a new one.
* Don't use `default_missing_value` for `override_version_using_short`
* Check errors by the API.
This changes the `disabled_version_long` and `disabled_version_short` tests.
This is opposed to comparing the stderr output.
* feat(arg_value): ArgValue can be used for possible_values
Through the ArgValue it is possible:
* `hide` possible_values from showing in completion, help and validation
* add `about` to possible_values in completion
* Resolved a few change-requests by epage
* make clippy happy
* add ArgValue::get_visible_value
* remove verbose destructering
* rename ArgValue::get_hidden to ArgValue::is_hidden
* add test for help output of hidden ArgValues
* Documentation for ArgValue
There is an issue that required to implement From<&ArgValue> for
ArgValue. We should probably find a solution without that.
* fix requested changes by epage
* fix formatting
* add deref in possible_values call to remove From<&&str>
* make clippy happy
* use copied() instad of map(|v|*v)
* Finishing up for merge, hopefully
* changes requested by pksunkara
This addresses a bug that causes duplicate flags reported in user-facing
error messages when two flags require one-another but also are required
under other conditions. The fix involves removing duplicates in unrolled
requirements, which addresses the user-facing aspect of this bug.
* Don't suggest `help` or `--help` when not applicable
* Apply suggestions from code review
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
* Update test usage to match intended
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Because we gradually build the `ArgGroup` as we parse the YAML, we don't
use `ArgGroup::new`. Clap3 introduced an internal `id` in addition to
the public `name` and it appears that this custom initialization code
was not updated.
This shows the problem with publically exposing `impl Default`.
Choices:
- Remove `impl Default`
- Always valid
- Requires spreading invariants
- Callers can't implement code the same way we do
- Add `ArgGroup::name`
- Can be constructed in an invalid state
- Centralizes invariants
- A caller could implement code like the yaml logic
I decided to go with `ArgGroup::name`.
Fixes#2719
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
Previously, we paniced. This is one less reason people have to call
lower level `get_matches` to get the commonly expected behavior, making
it more likely for the Rust community to "do the right thing"
Fixes#2659
