In experimenting on #1772, I want to write test cases for various
combinations of required or not, values vs occurrences, etc. There
wasn't really a clear place to put these.
On top of that, I wanted there to be a clear place in the tests for
describing the behavior of special types, to make it easier to audit and
easier to see how a PR for #1772 changes things.
As part of this effort in organizing these tests, I reduced the number
of tests that use special types. This better focuses these tests on the
cases they are intending to cover, rather than pulling in unrelated
features. This makes it easier to audit special types and makes it so
failures give more focused results, making it easier to see what broke.
`Parser::parse_from` will call `exit` on failure and we don't just lose
backtrace information but we don't even know which of the tests running
in parallel panicked. I ran into this when experimenting with
`clap_derive` and I couldn't tell what actually failed.
So let's switch to `Parse::try_parse_from`.
Errors went from:
```
test option_option ... ok
error: Found argument 'bar' which wasn't expected, or isn't valid in this context
USAGE:
clap_derive [OPTIONS]
For more information try --help
error: test failed, to rerun pass '--test arg_enum'
```
To:
```
test option_option ... ok
test variant_with_defined_casing ... ok
test skip_variant ... ok
test default_value ... ok
test vector ... FAILED
test option_vector ... ok
failures:
---- vector stdout ----
thread 'vector' panicked at 'called `Result::unwrap()` on an `Err` value: Error { message: Formatted(Colorizer { use_stderr: true, color_when: Auto
, pieces: [("error:", Some(Red)), (" ", None), ("Found argument '", None), ("bar", Some(Yellow)), ("' which wasn't expected, or isn't valid in this
context", None), ("\n\n", None), ("USAGE:\n clap_derive [OPTIONS]", None), ("\n\nFor more information try ", None), ("--help", Some(Green)), ("
\n", None)] }), kind: UnknownArgument, info: ["bar"], source: None, backtrace: Backtrace }', clap_derive/tests/arg_enum.rs:388:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
vector
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--test arg_enum'
```
In working on converting unwraps to errors, I noticed that we did not
spport `arg_enum` for `Option<Option<_>>` and `Option<Vec<_>>`, so this
addresses that.
My main motivation was to consolidate and make the logic more
consistent, the bug fix just fell out of that work.
In considering potential work for #2683, I realized we might need a type to carry data for
each of the `multiple_values`. `ArgValue` works both for that and for
possible values, so we need to come up with a better name for one or
both. Changing `ArgValue`s name now would be ideal since its new in
clap3 and by renaming it, we can reduce churn for users.
While thinking about this, I realized I regularly get these mixed
up, so renaming `ArgValue` to `PossibleValue` I think will help clear
things up, regardless of #2683.
Before #2005, `Clap` was a special trait that derived all clap traits it
detected were relevant (including an enum getting both `ArgEnum`,
`Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`,
`Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't
very descriptive.
This also helps further clarify the relationships so a crate providing
an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely
to choose the needed trait to derive.
Also, my proposed fix fo #2785 includes making `App` attributes almost
exclusively for `Clap`. Clarifying the names/roles will help
communicate this.
For prior discussion, see #2583
Right now
- `default_value="something"` is a raw method
- `default_value` uses native types
This commit splits the meanings
- `default_value="something"` is a raw method
- `default_value_t` uses `T::default()`
- `default_value_t=expr` uses an expression that evaluates to `T`
This is meant to mirror the `value_of` / `value_of_t` API.
At the moment, this is limited to `T: Display` to work with clap's
default system. Something we can look at in the future is a way to
loosen that restriction. One quick win is to specialize when `arg_enum`
is set. The main downside is complicating the processing of attributes
because it then means we need some processed before others.
Since this builds on `clap`s existing default system, this also means
users do not get any performance gains out of using `default_value_t`,
since we still need to parse it but we also need to convert it to a
string.
Fixes#1694
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
