We were storing data off into the struct, obscuring the direct
relationship between gathering and validating conflicts.
With this, not as much code needs to deal with mutable data
And other derive tweaks. I'm mixed on how far to go, including
- Linking to the derive reference
- Showing how to use each trait with both the derive and builder APIs
For now, this is an improvement.
Confirmed this works with [`argfile`](https://docs.rs/argfile/latest/argfile/)
And then running in clap
```
$ RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --all-features
```
They now show up!
While I'm unsure how much type specialization we should do, we
intentionally have the `arg_enum` attribute for doing special behavior
based on it, so let's take advantage of it.
Fixes#3185
The extra whitespace was targeted at machine processing for a subset of
users for a subset of runs of CLIs. On the other hand, there is a lot
of concern over the extra verbose output.
A user can set the help template for man, if desired. They can even do
something (env? feature flag?) to make it only run when doing man
generation. We also have #3174 in the works.
So let's focus on the end-user reading `--help`. People wanting to use
`help2man` have workarounds to do what they need.
Fixes#3096
The main care about is that when we override a `flatten` / `subcommand`
doc comment in a parent container, that we make sure we take nothing
from the child container, rather than implicitly taking one `about` ut
not `long_about`.
To do this, and to play the most safe with long help detection, we reset
`long_about` to default when there is no doc comment body to use for
`long_about`.
Fixes#2983
I dislike the inconsistency with only a few fields providing this (this
and `help_heading`) but this is to address a specific bug. We need to
visit this, along with iterators (#2870) and string handling (#2150).
`Arg` came along for the ride because the derive logic is applied to
both. `PossibleValue` didn't need it because we filter out `long_help`.
BREAKING CHANGE: We changed the signatures for `App::about`,
`App::long_about`, `Arg::help`, and `Arg::long_help` from accepting
anything `Into<&str>` to `&str`.
We have two ways of fixing this
- Making `--help` work
- Don't put `--help` in the help output
For now, I went with the latter. I tried to make it clear what the
actual requirement is so we can pivot if needed.
Fixes#2892
This happens to also fix the interaction of `DisableHelpFlag` with the
help subcommand and complcations. I've added a test to help catch if we
break this by changing how we fixed the original issue.
Fixes#2724
These issues were reported against clap3. I've not tried to reproduce
these in clap2 to see if they should show up in the release notes.
Without being a breaking change.
This seems minor enough that we can break this during the release
candidates. For `ValueHint`, the completion scripts are 99% of who
should be `match`ing it. `AppSettings` as undocumented variants that
people shouldn't use.
BREAKING CHANGE: `clap::{ValueHint, ErrorKind, AppSettings,
ArgSettings}` are now `non_exhaustive`.
