This broke when we introduced clap_lex and then did a refactor on top.
We put in guards to say that escapes shouldn't happen but missed `--=`
which isn't quite an escape.
Not fully set on what error should be returned in this case (we are
returning roughly what we used to) but at least
we aren't panicing.
Fixes#3858
Looks like I forgot to add a test case for this.
I put this in `clap_complete` because I expect `ValueHint` to move here
as we move towards a plugin system.
Fixes#3840
Between
- `ArgAction::SetTrue` storing actual values
- `ArgAction::Set` making it easier for derive users to override bool
behavior
- `Arg::default_missing_value` allowing hybrid-flags
- This commit documenting hybrid-flags even further
There shouldn't be anything left for #1649Fixes#1649
This adds a new `Cargo.toml` feature named `deprecated` that opts
controls whether deprecation warnings show up. This is starting off as
non-default though that may change (see below).
Benefits
- Allows a staged rollout so a smaller subset of users see new
deprecations and can report their experience with them before everyone
sees them. For example, this reduces the number of people who have to
deal with #3822.
- This allows people to defer responding to each new batch of
deprecations and instead do it at once. This means we should
reconsider #3616.
The one risk is people who don't follow blog posts and guides having a
harder time upgrading to the next breaking release without the warnings
on by default. For these users, we reserve the right to make the
`deprecated` feature `default`. This is most likely to happen in a
minor release that is released in conjunction with the next major
release (e.g. when releasing 4.0.0, we release a 3.3.0 that enables
deprecations by default). By using a feature, users can still disable
this if they want.
Thanks @joshtriplett for the idea
Though this is changing an API item we export, we do not consider this a
breaking change because
- This was an implementation detail of the macros and people shouldn't be using it directly
- The `macro_rules` macro is coupled to `clap` because they are in the
same crate
- The derive macro is coupled to `clap` because `clap` declares a
`=x.y.z` dependency on `clap_derive
Fixes#3828
