PR #1211 originally added `help_heading` with the current priority
(`App::help_heading` wins).
In #1958, the author had proposed to change this
> Note that I made the existing arg's heading a priority over the one in App::help_heading
This was reverted on reviewer request because
> Thanks for the priority explanation. Yes, please make the app's help
> heading a priority. I can see how it would be useful when people might
> want to reuse args.
Re-using args is an important use case but this makes life difficult
for anyone using `help_heading` with `clap_derive` because the user
can only call `App::help_heading` once per struct. Derive users can't get
per-field granularity with `App::help_heading` like the builder API.
As a bonus, I think this will be the least surpising to users. Users
generally expect the more generic specification (App) to be overridden by the
more specific specification (Arg). Honestly, I had thought this PR is
how `help_heading` worked until I dug into the code with #2872.
In the argument re-use cases, a workaround is for the reusable arguments
to **not** set their help_heading and require the caller to set it as
needed.
Fixes#2873
2871: Better positional checks r=epage a=pksunkara
2872: Iterate on help_heading to prepare for derive support r=pksunkara a=epage
2876: Generate/bash: add possible_values to completion when available r=pksunkara a=nstinus
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Co-authored-by: Ed Page <eopage@gmail.com>
Co-authored-by: Nicolas Stinus <nstinus@latourtrading.com>
Now that `help_heading`'s API is loosened with an `Into<Option>`, we can
more easily allow the existing yaml functionality to work. This still
misses the ability to set the help heading to nothing.
This reverts commit 9031deb806.
This makes `Some()` optional. This change was made with the derive API
in mind where you are unlikely to clear directly but we still need the
ability to clear.
In part, this is just fixing a papercut where someone will try to use
the API in the same way between the two but it fails and they'll have to
consult the docs / rust-analyzer.
The bigger reason is that this is more derive-friendly for dealing with #2803
since we will be able to just ask for the current help heading
before running the app and then restore it back, rather than having to
conditionalize the revert logic.
Problems with this
- It is incompatible with the new signature planned for
`App::help_heading`
- It is missing from `Arg` which is where this is more needed
- All this can do is set a global help heading because you can duplicate
keys (`clap_derive` has a similar problem but it at least has `flatten`)
For those that want the original behavior, you can usxe
`arg.help_heading(Some("FLAGS"))` on your flags. Limitations:
- This will not give you a special sort order
- This will not get a `[FLAGS]` added to usage
For templates, we removed `{unified}` and `{flags}`. To help people
catch these, a debug_assert was added.
I'm unsure but I think there might be a change in behavior in calcuating
when to show `[OPTION]` in usage. The old code only looked at
`required` while flags looked only at arg groups. We now look at both.
Ideally we'd add these in `_build` and remove special casing for
no-groups except in the sort order of groups. I feel like thats best
left for later.
This also reduced the scope of `App`s public API.
`get_*_with_no_heading` seemed a bit specialized to be in the public
API. #2853 looks at splitting it out into its own PR.
BREAKING CHANGE: Multiple
- `UnifiedHelpMessage` removed
- `{flags}` and `{unified}` are removed and will assert when present.
- `get_*_with_no_heading` removed
Fixes#2807
`App::get_matches` lazily post-processes `App`s and `Arg`s so we don't
do it to subcommands that are never run (downside being people have to
exercise their full app to get debug_asserts).
`clap_generate` was only post-processing the top-level `App` and `Arg`s,
ignoring the sub-commands. In #2858, we noticed that `--version` was
being left in the completions instead of being removed during the
`_build` step. We would also have an incorrect `num_vals` and a host of
other problems.
This change adds a `App::_build_all` function for `clap_generate` to use
to eagerly build everything. By having it there, we make sure
everywhere that needs eager building, gets it (like some tests).
In `clap_generate::utils`, we add a unit test to ensure the subcommand's
`--version` was removed.
For some other tests specifying `.version()`, I added
`AppSettings::PropagateVersion` to make it behave more consistently.
The places I didn't were generally where the version was conditionally
set.
For `clap_generate/tests/generate_completions.rs`, I had to adjust the
`conflicts_with` because the subcommand was inheriting the argument with
it defined *but* the subcommand did not have the argument, tripping up a
debug assert.
Fixes#2860
This partially reverts commit 7f627fc.
This reverts the error code change but not the `ErrorKind` change. I
was mixed on whether we should do that or not. The benefit is it makes
it so people can check the Kind for cases like #2021. On the other
hand, it doesn't seem that hard to re-implement the feature.
Fixes#2767
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)
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
Instead they should behave like `default_value`/`default_values`.
In implementingt this, I didn't see any reason to be using a `VecMap`.
In fact, this helped simplify the code / make intent clearer.
With this, we are also able to simplify the derive macro work from #2633.
Fixes#2634
BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather
than append. We expect the impact to be minimal.
Rename needs_valueof to parse_result
Use ParseResult more
Less predicting, more fallback
Remove non-sense ParsingResult::NotFound
Merge FlagSubCommand and FlagSubCommandShort
Merge NoMatchingLongArg and NoMatchingShortArg
Better documentation for pos_counter bumping
Denoise of pos_counter
Split ParseState from ParseResult
Remove ParseResult::Flag
small cleanup
When using `#[clap(flatten)]` inside of a `Subcommand`, we would do a
`from` instead of an `update`.
The challenge is knowing when we are
going into a flattened subcommand vs changing the variant. To resolve
this, I added a `Subcommand:has_subcommand(name)` trait method that we
generate, so we can ask.
Improved the `impl`s of `From` for `&'help Yaml` to use expects with useful messages instead of unwraps. Also made changes to avoid potentially fetching redundant data from YAML hashes and unwrapping the same data multiple times. Finally, there are tests to ensure the panics are correct.
PR #1637 switched clap to report `64` on errors and then #1653 switch it
to `2`, but both missed a case. This also documents the reason why inline
since I had to go and dig through the history to re-discover the
motivation.
Before, partial command lines would panic at runtime. Now it'll be a
compile error
For example:
```
pub enum Opt {
Daemon(DaemonCommand),
}
pub enum DaemonCommand {
Start,
Stop,
}
```
Gives:
```
error[E0277]: the trait bound `DaemonCommand: clap::Args` is not satisfied
--> clap_derive/tests/subcommands.rs:297:16
|
297 | Daemon(DaemonCommand),
| ^^^^^^^^^^^^^ the trait `clap::Args` is not implemented for `DaemonCommand`
|
= note: required by `augment_args`
```
To nest this, you currently need `enum -> struct -> enum`. A later
change will make it so you can use the `subcommand` attribute within
enums to cover this case.
This is a part of #2005
While having convinience derives can be helpful, deriving traits that
are not used in similar situations (`Clap` and `ArgEnum`) can make
things harder
- From a user, derives are opaque and create uncertainty on how to use
the API if not kept crystal clear (deriving a name gives you the trait
by that name)
- This makes documentation harder to write and read
- You can use types in unintended places, which is made worse for crate
APIs because changing this breaks compatibility.
Fixes#2584
* add a new arg option for the max_occurrences
* check ErrorKind in tests
* Updated grammer in doc comments
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
* assert is_err() before unwraping
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
* docs: fix links to Subcommand
These were broken by 03333800fe
* docs: remove crate links from body content
Addresses code review
* docs: allow some room to breath
Addresses code review
* refactor(validator): use filtermap style for `gather_conflicts` and `validate_exclusive`
* refactor(validator): remove nested `filter`s in `build_conflict_err_usage`
* refactor(validator): add more code beautifying
* refactor(validator): revert some unnecessary changes
* refactor(validator): revert some unnecessary changes, take 2
* fix(wip): add necessary debugging prints for analysis
* fix(wip): implement the fix, take 1
* docs: add docstring for `Parser::flag_subcmd_at` and `Parser::flag_subcmd_skip`
* test: make `flag_subcommand_short_after_long_arg` test more realistic
Refactoring and better test cases
Refactored SubcommandHelpShowsLongForm to
UseLongFormatForHelpSubcommand.
Tests and docuemntation examples use about and long_about instead of
(before/after)_help.
Removed commented out tests
Linting: Fix trailing new line
Updated change log, refactored tests and doc str
Reordered items in the Changelog
New test added and old tests removed that were redundant
Doc string for AppSettings::UseLongFormatForHelpSubcommand fixed
Change default help template:
- The new template introduce new lines before and after
author/about sections.
- Add help template placeholders:
- about-section
- author-section
- Documentation of new placeholders in clap::App::help_template
- Update all unit tests by incorporating new lines
Following changes are implemented:
- Add 'clap::Arg::get_visible_aliases(&self)' method
This new method provides access to visible argument aliases
- Add 'clap::Arg::get_short/long_and_visible_aliases
This new method provides access to the short/long arguments and its
visible aliases
- Add visible aliases completions in clap_generate for following shells:
- Bash
- Elvish
- Fish
- Powershell
- Zsh
- Add test fixtures for testing visible alias completions in clap_generate:
'clap_generate/tests/completions/<shell>::<shell>_with_aliases()'
This removes the direct dependency on unicode-width and delegates the
complexity of computing the displayed width of text to the Textwrap
crate.
The `display_width` function handles characters like “æøå” (Danish),
“äöü” (German), and “😂✨😍” (emojis) – even if the unicode-width
Cargo feature is disabled.
This is an improvement of the former `str_width` function which would
over-estimate the width of emojis and non-ASCII characters (since they
are several bytes wide).
* docs: Correct method name in example
This looks like it was copied from the documentation for
`required_unless_present_all` but not updated accordingly for this
method.
* docs: Add note re `required_unless_present_all` to `required_unless_present_any`
There's a note in the documentation for `required_unless_present_all`
telling users to check out `required_unless_present_any` if that's what
they want. I figured it might be useful to have a similar note in the
documentation for `required_unless_present_any` pointing to that method
as well.
* docs: Fix `required` link in docs for `required_unless_present_all`
* docs: Correct "if" to "unless"
zsh completion generation would panic if a global argument
had conflicts with another argument which was present in its
own command but not in its subcommands
Add the suggested changes
Fix test issue_1050_num_vals_and_defaults
It used a required which isn't needed for the purpose of the test.
Add tests for the default+required assertions
Add test for positional args with long or short
These links were broken but rather than fix them, let's just remove them
since they're inside the documentation for the function that they link
to which seems unnecessary.
These links were broken but rather than fix them, let's just remove them
since they're inside the documentation for the functions that they link
to which seems unnecessary.
This link was broken but rather than fix it, let's just remove it since
it's inside the documentation for the function that it links to which
seems unnecessary.
2172: Don't use default value when option is passed r=pksunkara a=davidhewitt
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Some more fixes in addition to 594c535ba2
* Some I noticed manually.
* Some were found by Topy (https://github.com/intgr/topy), either new
rules from Typo or new code in clap.
* `etc.` and `e.g.` rules were disabled during the last run.
Argument prefixed by `-` will never inferred as a subcommand
Suggest using subcommand when supplied after `--`
Cargo fmt, adding test for wrongly using subcommand after `--`
Fix test
Fix clippy
As previously discussed on [GitHub], this commit introduces a Cow-like
wrapper RegexRef to enable both `Regex` as well as `&Regex` as
arguments.
It also introduces a new module in the `build:arg` path to remove
clutter from the main module. For more information see #2073.
[GitHub]: https://github.com/clap-rs/clap/pull/2073#issuecomment-674442310
This commit introduces a new feature called `"regex"`. It adds a new
function `validator_regex` to `Arg` and was inspired by the discussion
in #1968. The name `validator_regex` was chosen instead of
`regex_validator` to make sure that the developer keeps in mind that
there may only be a single `Validator` on an `Arg`.
The feature can be used with YAML files, however there is no proper
pattern in `clap_app!` (yet).
2100: Allow for nested subcommands with ZSH generation. r=pksunkara a=newAM
2106: Update the env var example for derive r=pksunkara a=rgreinho
Co-authored-by: Alex M <alexmgit@protonmail.com>
Co-authored-by: Rémy Greinhofer <remy.greinhofer@gmail.com>
The macro `yaml_opt_str` is only used in `yaml_tuple3`, which again is
only used for `default_value_if`. Unfortunately, the current test
doesn't make sense, as a v.is_null() indicates a Yaml::Null, on wich
`as_str()` always returns `None`. Instead, the condition should be
negated, as the documentation of `default_value_if` hints:
> **NOTE:** If using YAML the values should be laid out as
> follows (`None` can be represented as `null` in YAML)
The case `$v.is_null()` should therefore lead to `None`, whereas all
other cases should be interpreted `as_str()`.
Previously there were separate tags for this, {before-help-padded} and
{after-help-padded}. Those have been removed and the default ones
given their behavior.
This makes some changes to the template system:
- Template tags for optional items (like {author}) now expand to
nothing when the value is unset instead of a default string (like
"unknown author").
- Many template tags now emit line-wrapped output to match
write_default_help.
- Items with long variants now expand to the appropriate thing for -h
vs --help.
- The now-obsolete {long-about} tag has been removed.
- A few new tags have been added.
These are externally-visible changes, but if this makes it into 3.0
that's probably reasonable?
Note that line-wrapping can have some odd edge cases since it does not
account for preceding/trailing characters on the same line as the tag.
This is already the case in master, but will affect some additional
tags with this changeset. See #2065 for details.
Closes#2002.
Adds new method/attribute `Arg::value_hint`, taking a `ValueHint` enum
as argument. The hint can denote accepted values, for example: paths,
usernames, hostnames, commands, etc.
This initial implementation supports hints for the zsh and fish
completion generators, support for other shells can be added later.
2016: imp(errors): Provide the missing required arguments as info r=CreepySkeleton a=nickelc
Co-authored-by: Constantin Nickel <constantin.nickel@gmail.com>
When debug_assertions flag is active, properly handles conflicts between
flag subcommands short and long their aliases and args and their
aliases prevents self conflicts where the alias and the flag subcomand
were the same.
No longer abusing external_subcommand, but using subcmd_name in order to
parse a subcommand, added a `keep_state` variable in order to handle the
hacky solution of short command line arguments.
Instead of a `FlagSubCommand` struct the addition of two simple methods
to `App`. `App::long_flag` and `App::short_flag` that cover all the
bases of the many methods that were provided in `FlagSubCommand`. This
API is far simpler to use and more akin to the present `Arg::long` and `Arg::short`.
this implements Arg::short_alias, Arg::short_aliases,
Arg::short_visible_alias, and Arg::short_visible_aliases in addition to
adding their associated tests
