This is a followup to #2721 where we decided to remove all of the
helpers from the trait. They are now in a `utils` mod. A part of me
wants this module to be private but it'd be a lot to duplicate for the
split out modules.
Note: this doesn't update fig. Fig was never added to the workspace and
is already broken (and not just from #2721). My plan is to get this
merged and then fix Fig, rather than fix it in multiple passes.
2829: [clap_generate] [zsh] sort out multiple occurrence vs multiple_value. r=pksunkara a=pseyfert
Co-authored-by: Paul Seyfert <Paul.Seyfert@sevensense.ch>
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.
