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
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
- help / version flag report correct application name when generated
with clap_derive and an Enum.
- add clap_derive unit tests for application name:
file: clap_derive/tests/app_name.rs
tests: app_name_in_[short|long]_[help|version]_from_[struct|enum]()
In the `Clap` derive macro, a function parameter named `arg_matches` is
generated using `quote!` - as a result, this parameter ends up with
call-site hygiene. However, `arg_matches` is written literally within
several `quote_spanned!` blocks, which generate an `arg_matches` token
with the hygiene of whatever span was passed to `quote_spanned!`.
If these two hygienes are different (for example, if the user invokes
the derive macro from a `macro_rules!` macro), then a usage of
`arg_matches` may not resolve to the `arg_matches` parameter definition.
This commit changes the generation of `arg_matches` identifiers to
always use `quote!`, ensuring that they will always be considered the
'same' identifier by Rust.
Updates the derive example handling environment variables to illustrate
the case where it contains a sensitive value which should not be
displayed on the help screen.
Closes https://github.com/clap-rs/clap/issues/2101
Due to macro expansions, a `syn` type may be wrapped in multiple
'layers' of `syn::Type::Group`. However, `clap_derive` currently does
not check for `syn::Type::Group`, which will cause an `Option` (along
with other matched types) to fail to be detected when it results from a
macro expansion.
This commit 'unwraps' outer type groups before checking the
user-provided types against well-known types. Currently, these groups
may not be present due to a rustc bug (rust-lang/rust#43081)
However, once https://github.com/rust-lang/rust/pull/73084 is merged,
these groups will be present in more cases. This commit makes `clap`
compatible with both older and newer versions of rustc.
This PR switches the Arg::Short macro to take a character instead of a string. It removes the hacky code in the Method to_token method and implements the logic for Short when parsing the clap derive arguments.
Fixes#1815.
1689: Remove some mentioning of structopt r=TeXitoi a=CreepySkeleton
A work on #1671. Attention! It doesn't close it just yet
Co-authored-by: CreepySkeleton <creepy-skeleton@yandex.ru>
1681: WIP: Extract subcommands into separate trait r=pksunkara a=CreepySkeleton
Not-yet-working-but-almost-there "multiple traits" approach. More or less done, what's left is to catch some bugs and adapt tests/examples.
For the record: it took so long because of RL stuff (who would have thought?) and because [there was a detailed description of the experience I've had here, but it was deleted because it contained a lot of profanity and emotional notes].
As the only person alive that understands how the derive works (if you won't blow your own horn, nobody will do it for you, yeah), I'd like to made a statement: we Do need the refactoring.
Co-authored-by: CreepySkeleton <creepy-skeleton@yandex.ru>
1678: Refactor clap_generate r=CreepySkeleton a=pksunkara
I have copied the code from [clap_generate]( https://github.com/clap-rs/clap_generate) and refactored the structure a bit.
This new structure will allow people to write their own generators using our `Generator` trait which will contain some helpers (Still working on polishing them).
Co-authored-by: Ole Martin Ruud <barskern@outlook.com>
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
1664: Import structopt r=pksunkara a=CreepySkeleton
OK, here is about 50% of what's left to import.
`impl StructOpt for Box<impl StructOpt>` is not imported because layouts of `StructOpt` and `Clap` are too different. I'll work it out after the import is done.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/clap-rs/clap/1664)
<!-- Reviewable:end -->
Co-authored-by: CreepySkeleton <creepy-skeleton@yandex.ru>
Co-authored-by: Cecile Tonglet <cecile.tonglet@cecton.com>
Co-authored-by: David McNeil <mcneil.david2@gmail.com>
