This was changed in #1989 without an explanation:
- In the help template, there isn't a way to expose with help_headings,
so show all.
- In usage, we don't know whether the user wants to see `[FLAGS]` /
`[OPTIONS]` or not, so let's default to showing them.
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)
When removing `concurrency`, I overlooked this case where we want to
serialize deployments.
Queuing deployments also doesn't give us much. I switched from using an
action for this to using built-in support.
2823: fix(derive): Subcommands not working within macro_rules r=epage a=epage
2824: docs(derive): Fix explanation on optional string list argument r=epage a=epage
2827: feat: Add backtraces to errors r=epage a=epage
Co-authored-by: Ed Page <eopage@gmail.com>
2821: test(derive): Port structopt flatten coverage r=epage a=epage
2822: feat(derive): Add support for lower/upper in rename_all r=epage a=epage
Co-authored-by: Ed Page <eopage@gmail.com>
This carries over a test case from
https://github.com/TeXitoi/structopt/pull/448, and re-fixes it according
to the changes we've made since we forked. I also tried to identify
other cases and quote them to avoid playing whack-a-mole with this.
This is a part of #2809
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
