This feature is too immature at this stage in the release. See
clap-rs/clap Issue 3020 when bringing this feature back.
This reverts commit 301c6f765a.
This reverts commit 43a4c90c86.
This reverts commit 4e29777b21.
This reverts commit 69957c4ddd.
This reverts commit bdb1d324a5.
This reverts commit b102da0cd2.
This reverts commit 72429be14e.
This reverts commit 0b7def675b.
This reverts commit b86aa631be.
This reverts commit 6b458c602d.
Not seeing what this example adds over the other ones. We've already
shown subcommands and shown that `App` has extra behavior for when
definint subcommands.
This better models what users should be doing and makes it so all
comments are more clear. In a prior commit, when a changed an `exit` to
`unwrap`, I disliked the fact that I was mixing an unwrap explanatory
comment in with another comment. This makes them stand apart.
The subcommand examples focus on the various ways of looking up
subcommands except for the main one people should be using. This has
previously caused confusion, see https://github.com/clap-rs/clap/discussions/3000
To keep the examples focused, I only show `ArgMatches::subcommand`. I
figure the examples are not exhaustive and that for the cases when
someone wants to do something more specialized, they can pull up the
API reference.
The comments in these examples say that a `conflicts_with` should
override `required`. This seems to be true one way but not the other,
causing these examples to error out at runtime.
This consolidates two `crate_*!` macro examples into a `app_from_crate`
example.
- This is more of what we expect users to use
- We've talked about splitting the `crate_*` macros out into their own
crate. This shifts the focus to what clap would be providing long
term
Looks like this is coming from `update_from_arg_matches` where we do a
ladder of `if __clap_arg_matches.is_present(...)` that clippy wants to
be `else if`s. While for human edited code, that does clarify intent,
for machine generated code that is rarely read, its a pain to do, so
silencing it.
Unfortunately, it isn't in a group we can overall silence.
Fixes#3017
This reverts commit 6898fbde33.
PR #2144 added the `license` field but no consumer has been added since
the (like Issue #1768). Since this is not ready yet, I am pulling it
from the 3.0 release.
So far, our main route for pulling a feature from the release has
been to put it behind a `unstable-*` feature flag and to create a
stablization tracking issue. I chose to instead remove the feature
because a write-only field with no effect does not provide values for
people to use in as an early access and so doesn't outweight the cost of
the extra documentation noise and code noise it creates. Additionally,
keeping an `unstable-` feature around when it has such an unknown path
(and time table) to stalbization feels like it violates YAGNI. I'm
uncertain how much of this feature we can implement and not create a
legal trap for users because the crate's license is insufficient for the
final artifact's license. I feel our stabliazation process sshould be
about iteration and collecting user feedback which this doesn't line up
with.
When someone is ready to tackle #1768, it will be easy to revert this
commit and pick up the work again.
Fixes#3001
