The overall hope is to allow a `&'static str`-only version of clap, so
we need to move off of `Str` where dynamic strings are required. We
need it here for subcommands due to external subcommands.
This had minimal impact on code size (567.2 to 567.5 KiB)
Originally, I saw the ideal as the parent command being isolated from
`#[clap(flatte)]` especially after all of the doc comment
leakage issues. We scaled that back to just `next_help_heading` because
of the issues with settling on a policy and maintenance to cover
everything. When doing `next_display_order`, we decided it would mess
things up too much to isolate it.
With #1807, we instead have been moving towards setting
`#[command(next_help_heading)]` anywhere, we just need to finish working
out how it should work.
Since the `name` is changed to be the package name, we can't use it as
(1) its not as predictable and (2) it can lead to conflicts if a
`Parser` is flattened into a `Parser`
When I removed these in v5, we didn't have a deprecation approach for
the derive and I didn't want to forget. Now we do have a deprecation
approach and that is the reminder, so we don't need to carry around v5
changes.
The builder function was deprecated in v3 and removed in v4 but the
derive masked that, so we're still adapting things but now with a path
towards removal.
Another step towards #1041
This isn't the long term type for `PossibleValue::help`, I just wanted
to get the lifetime out of the way first before figuring out how help
will work.
The main breakinge change cases:
- `&[char]`: now requires removing `&`
- All other non-ID `&[_]`: hopefully #1041 will make these non-breaking
Fixes#2870
Previously the Arg id was set with the "name" attribute. This allows use
of an "id" attribute to match the underlying struct.
A side effect of this is that the "id" attribute may also be used on
Commands. This isn't desired, but given the current architecture of the
attribute parser, it's hard to avoid.
Fixes: #3785
This reduces ambiguity in how the different "multiple" parts of the API
interact and lowrs the amount of API surface area users have to dig
through to use clap.
For now, this is only a matter of cleaning up the public API. Cleaning
up the implementation is the next step.
This changes the default type as well to encourage preserving the full
information for shelling out. If people need UTF-8, then they can
change the value parser.
Fixes#3733
The main goal is to reduce the risk of people developing on the wrong
release, assuming they are using something like starship to raise the
visibility of the crate version.
When upgrading our company projects from clap 3.1 to clap 3.2 I had
to fix several references to `clap::lazy_init`. People are not
supposed to do that, but that's hard to enforce.
Hope placing `once_cell` reexport into `__macro_refs` prevent at
least some of the such issues in the future.
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
Putting it on the doc comment is weird. We are now putting it on the
field which is a slight improvement. This better conveys "this is
auto-generated".
No test was added because the use case that I know of for exposing this
is short lived.
We aren't enumerating arguments but values for an argument, so the name
should reflect that.
This will be important as part of #1807 when we have more specific
attribute names.
For programs opting into the clap v4 behavior (with `action` or
`value_parser` attributes), we'll no longer generate a
`multiple_occurrences(true)` call in preparation for deprecating
`multiple_occurrences`. See #3772.
This is the derive support for #3774 (see also #3775, #3777)
This combined with `value_parser` replaces `parser`. The main
frustration with this is that `ArgAction::Count` (the replacement for
`parse(from_occurrences)` must be a `u64`. We could come up with a
magic attribute that is meant to be the value parser's parsed type. We
could then use `TryFrom` to convert the parsed type to the user's type
to allow more. That is an exercise for the future. Alternatively, we
have #3792.
Prep for this included
- #3782
- #3783
- #3786
- #3789
- #3793
This will make it easier to divide off parser logic for adding in
actions.
This does mean we can't provide error reporting on bad values with
`bool` but
- We should have also been doing that for `from_flag`
- We'll be dropping this soon in clap4 anyways
Clap has focused on reporting development errors through assertions
rather than mixing user errors with development errors. Sometimes,
developers need to handle things more flexibly so included in #3732 was
the reporting of value accessor failures as internal errors with a
distinct type. I've been going back and forth on whether the extra
error pessimises the usability in the common case vs dealing with the
proliferation of different function combinations. In working on
deprecating the `value_of` functions, I decided that it was going to be
worth duplicating so long as we can keep the documentation focused.
The remove functions no longer return `Arc` but the core type, at the
cost of requiring `Clone`. I originally held off on this
in #3732 in the hope of gracefully transition the derive and requiring
`Clone` would have been a breaking change but when it came to #3734, I didn't
find a way to make it work without a breaking change, so I made it
opt-in. This means I can force the `Clone` requirement now.
I added the requirement for `Clone` everywhere else in the hopes that in
the future, we can drop the `Arc` without a breaking change.
For clap 3, its opt-in as a precaution against breaking
compatibility in some weird cases.
This does require the types to implement `Clone`.
Fixes#3734Fixes#3496Fixes#3589
In case the `ArgMatches` is cloned, this forces a constraint that the
underlying type impls `Clone` but that should be safe as we only support
`String` and `OsString`.
