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
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>
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
Some programs do not use anything to separate word boundaries.
For example a struct may contain the field `build_dir` while the flag is
`--builddir`.
This is a port of https://github.com/TeXitoi/structopt/pull/412
This is part of #2809
https://github.com/TeXitoi/structopt/pull/325 special cased `version`
because a default method would be added if the user did nothing, which
caused problems when nesting subcommands. We no longer apply that
default method and the highest item in the chain always has precedence,
so this can be simplified / clarified.
This will unblock us from removing the `version` hack because we'll
always get the right precedence.
Later we can explore ways of moving the app methods to being done first.
The big problem is with `#[clap(subcommand)]` because we need to call
those app methods on the subcommands `App` *and* override them with app
methods on the variant, requiring the app methods to be last to get
precedence.
Before there was no way to make `SubcommandsNegateReqs` with
`clap_derive` because it required a required field with a sentinel value
for when the required part was negated. We blocked that.
This turned out simpler than I expected.
This came out of the discussion for #2255 but that issue is more
specifically about the panic, so not closing it.
* 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
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
I did some digging to root cause this but gave up and suppressed it,
like others. Warnings like this also come with a cost of code-gen
complexity.
Fixes#2712
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.
Right now
- `default_value="something"` is a raw method
- `default_value` uses native types
This commit splits the meanings
- `default_value="something"` is a raw method
- `default_value_t` uses `T::default()`
- `default_value_t=expr` uses an expression that evaluates to `T`
This is meant to mirror the `value_of` / `value_of_t` API.
At the moment, this is limited to `T: Display` to work with clap's
default system. Something we can look at in the future is a way to
loosen that restriction. One quick win is to specialize when `arg_enum`
is set. The main downside is complicating the processing of attributes
because it then means we need some processed before others.
Since this builds on `clap`s existing default system, this also means
users do not get any performance gains out of using `default_value_t`,
since we still need to parse it but we also need to convert it to a
string.
Fixes#1694
It looks like CI hasn't been running on this and we've introduced some
problems. It looks like we had an off-by-one error in the check for
MSRV for deciding to run ui tests.
It turns out `value_name` appends, so by setting an implicit and
explicit `value_name`, the user gets both and `num_vals=2`.
There is still a question on `value_name` and whether its documentation
or behavior needs updating. If that changes, then this can be
simplified by reverting back.
Fixes#2632
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.
I debated putting this fix inside of the Builder API but I figure this
makes it so you "pay for what you use", with the derive API giving it to
you "for free".
A potential next step is to improve the default value name. I tend to
use value_name to hint at how to use an argument, which correlates with
types. We could add a
`ValueName::value_name(fallback: &str) -> &str` with impls for common
types, so we get more of a usage-based result.
Fixes#2608
One of the challenges with #2255 is for the user to discover whats going
wrong. This helps by at least telling people how they got into a bad
state and we can search for the code within the derive.
Before, when doing an `update` involving subcommands, we generated
parsing rules for the `from` case instead, requiring all arguments to be
present.
This switches us to descending into `update` code and adds tests to
verify it works.
This is a part of #2605
When debugging #2586, I noticed we were developing match cases for
variant names that were flattened. At minimum, this is dead code and at
worst this could cause the wrong behavior if a user does an update with
one of those names.
Depends on #2587Fixes#2588
`structopt` originally allowed
```
pub enum Opt {
Daemon(DaemonCommand),
}
pub enum DaemonCommand {
Start,
Stop,
}
```
This was partially broken in #1681 where `$ cmd daemon start` works but `cmd daemon`,
panics. Originally, `structopt` relied on exposing the implementation
details of a derived type by providing a `is_subcommand` option, so we'd
know whether to provide `SubcommandRequiredElseHelp` or not. This was
removed in #1681Fixes#2005
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
