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
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.
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.
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, 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
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
