Unrolling serves two distinct purposes but we muddied them together
- Is `requires` satisfied for validation
- Report what arguments are currently considered required for usage
This was split out of #3020
For the derive API, you can only call `next_display_order` when dealing
with a flatten. Until we offer app attributes on arguments, the user can workaround with
this no-op flattens.
This is a part of #1807
This clarifies the intent and prepares for other functions doing the
same, like `next_display_order`. This will then open us to name
`subcommand_help_heading` and `display_order` similar.
The deprecation is waiting on 3.1.
This is part of #1807 and #1553.
This is inspired by cargo which allows you to run `cargo test --test`
and it will list the possible tests (obviously we can't support that atm
because that requires a lot of runtime processing). When we do have a
static list of possible values, we can at least show those.
Fixes#3320
For some errors, we use the unroll logic to get the list of required
arguments. The usage then does the same, but without a matcher. This
was causing the lists to not match.
As a side effect, this fixed an ordering issue where we were putting the
present arg after the not-present arg. I assume its because we ended up
reporting the items twice but the first time is correctly ordered and
gets precedence.
This was split out of #3020
In clap2, `ArgMatches.args` was public but hidden. We made it private
in clap3, giving us more implementation flexibility but many people
relied on it, like to short-circuit defaulting, providing their own
`ArgRequiredElseHelp`, etc.
The main problem was how to expose this
- If we think of `ArgMatches` as a container (a DAG), should we have an
`is_empty` and what all is included in that, like subcommands?
- If we focus on only args, what term how do we refer to this to convey
the right intent?
In the end, I realized that this aligns most with our existing
`is_present` check and reporting if args are present fits the best
within the existing API.
I looked into also exposing iterating over the args (`present_arg_ids`)
but we have no way to expose the Id. The Id is currently private and if
we made it public, it can't be used to access any arg because it can't
implement `Key`.
This supersedes #3265
If a value must be reused later then it's better to pass it as a &str
instead of cloning it, that means the clone happens in a central
place (inside the method).
By never passing a &String those instances of the method are not monomorphized.
Saves only 0.5K, maybe not worth it in hindsight.
This is an initial implementation with plenty of room to grow, including
- Allowing pulling out a subset of the generated man page for greater customization
- Subcommand handling
- Extra sections
- Consolidate argument formatter after #2914Fixes#552
When an Arg uses .min_values(0), that arg's value(s) are effectively
optional. This is conventionaly denoted in help messages by wrapping the
arg's values in square brackets. For example:
--foo[=value]
--bar [value]
This kind of argument can be seen in the wild in many git commands; e.g.
git-status(1).
Signed-off-by: Peter Grayson <pete@jpgrayson.net>
We were only tracking the last value source (default, env, cli, etc).
This works for args because they only come from one source. Groups
however can come from multiple sources and this was making us treat a
group with a default value as being completely from defaults despite
some values maybe being from the commandline.
We now track the highest precedence value for a group.
Fixes#3330
I thought I was adding a test in #3305. Maybe I considered the
clap_complete changes sufficient for this. Doing more `debug_assert`s
would be good also.
Unsetting `PropagateVersion` helps in some cases but we need to unset it
globally to override the global propagation.
Fixes#3310
We might be able to handle version/help before propagation but I didn't
want to hold up this fix for that to happen and increase the risk
associated with this fix.
Fixes#3298
This will help prevent issues from being deployed to users like in #3281
I do not consider this a breaking change because any normal operation
will assert anyways.
Cargo is an example of a user that heavily relied on using undefined
names because there is a lot of code sharing between commands. This
allows a path forward for those users that is just painful enough to
discourage overly relying on it in the future :).
`clap_generate` originally intended to be "generate anything". With
`fig`, we already broke one part out. With #3174's man support, we are
also looking at keeping it separate:
- More freedom to iterate on the API
- Uniqueness (and potential weight) of its dependencies
- man generation is normally more for distribution while completions are
a mix of being distributed with the app or the app generating the
completions (which will be exacerbated if we move most completion
parsing logic to be in Rust)
So `clap_generate` is having a lot more limited of a role than the
original name conveys. I worry the generic name will be a hindrance to
people discovering and using it (yes, documentation can help but there
are limits).
I hesitated because we are on the verge of releasing 3.0. However, doing
it even later will be even more disruptive because more people will be
using it (crates.io lists ~70 people using `clap_generate`).
To ease things, we are still releasing `clap_generate` as a wrapper
around `clap_complete`.
