Ed Page
f54bcc85b7
feat(error: Expose missing-subcommand context
2022-02-04 13:18:51 -06:00
Ed Page
9b18f8087c
feat(error: Expose missing-required context
2022-02-04 12:45:48 -06:00
Ed Page
71535866b9
feat(error: Expose invalid-subcommand context
2022-02-04 12:23:06 -06:00
Ed Page
5095e5c992
feat(error: Expose unrecognized-subcommand context
2022-02-04 11:15:22 -06:00
Ed Page
1a0d7bac29
feat(error: Expose invalid-value context
2022-02-04 10:24:51 -06:00
Ed Page
04aa6029b8
refactor(error): Generalize kind name
2022-02-04 10:08:51 -06:00
Ed Page
1463f82cf1
feat(error: Expose no equals context
2022-02-04 10:07:14 -06:00
Ed Page
9759f2f1ea
refactor(error): Share template across kinds
2022-02-04 10:03:09 -06:00
Ed Page
630e7097fc
feat(error: Expose empty value context
2022-02-04 10:01:07 -06:00
Ed Page
0c36fc2073
feat(error): Expose argument conflict context
2022-02-04 09:59:06 -06:00
Ed Page
7029e76545
refactor(error): Prepare for deferring formatting
2022-02-04 09:56:22 -06:00
Ed Page
c002951dc8
refactor(error): Centralize app knowledge
2022-02-04 09:51:34 -06:00
Ed Page
ee63f6cd9b
refactor(error): Prepare for optional deferred formatting
2022-02-04 09:45:12 -06:00
Ed Page
af41e8d6b2
refactor(error): Separate try_help concerns
2022-02-04 08:49:55 -06:00
Ed Page
8de99407f9
feat(error): Impl Display for ErrorKind
2022-02-04 08:37:23 -06:00
Ed Page
4add5723ec
refactor(error): Don't constrain start of errors
...
This also makes the intent for the start of an error clearer.
2022-02-04 08:21:24 -06:00
Ed Page
70b830a1ad
refactor(error): Prepare for adding more app fields
2022-02-03 13:05:10 -06:00
Ed Page
00af9c11f8
refactor(error): Shift focus to modern fields
2022-02-03 12:59:59 -06:00
Ed Page
27469dc740
refactor(error): Centralize new formatting
2022-02-03 12:36:20 -06:00
Ed Page
1b66585dc2
feat(error): New error context API
...
This is meant to replace `Error::info` as part of #2628 .
2022-02-03 12:30:49 -06:00
Ed Page
d1a6cca480
docs(readme): Link out to shadow for long_version
...
This seems like a case where we shouldn't solve all the problems but
point to others who do.
Fixes #1363
2022-02-03 08:43:17 -06:00
Ed Page
7b0b0cfae2
Merge pull request #3396 from epage/split
...
refactor(error): Split up error mod
2022-02-02 18:05:22 -06:00
Ed Page
59b63aea51
refactor(error): Pull out kind mod
2022-02-02 16:13:26 -06:00
Ed Page
2d01331540
refactor(error): Prepare for splitting mod
2022-02-02 16:06:23 -06:00
Ed Page
7ca872e7bb
Merge pull request #3395 from epage/box
...
refactor: Prepare for replacing `info`
2022-02-02 15:59:20 -06:00
Ed Page
03832c75b9
refactor: Reduce reliance on soon-to-deprecate kind
2022-02-02 15:47:47 -06:00
Ed Page
3b516a4d62
perf(error): Reduce stack size of Error
2022-02-02 15:46:45 -06:00
Ed Page
a889797c27
fix(error): Allow Result interoperability
2022-02-02 15:43:07 -06:00
Ed Page
b538a43961
refactor(error): Switch to error::ErrorKind
2022-02-02 15:41:24 -06:00
Ed Page
5535f49d13
fix(error): Expose the error module
...
We'll be expanding whats included and we shouldn't spam the root as
much.
2022-02-02 15:35:20 -06:00
Ed Page
b55edfa740
refactor: Rename errors mod
...
It seems that `error` is more common (e.g. `nom`)
2022-02-02 15:34:17 -06:00
Ed Page
6638fc4e2d
Merge pull request #3394 from epage/possible
...
feat(error): Show possible values when none are supplied
2022-02-02 14:49:36 -06:00
Ed Page
9d482d00ba
feat(error): Show possible values when none are supplied
...
This is inspired by cargo which allows you to run `cargo test --test`
and it will list the possible tests (obviously we can't support that atm
because that requires a lot of runtime processing). When we do have a
static list of possible values, we can at least show those.
Fixes #3320
2022-02-02 14:28:41 -06:00
Ed Page
d4cfceedab
Merge pull request #3391 from epage/possible
...
fix(error): Consistently respect possible values order
2022-02-02 14:11:19 -06:00
Ed Page
6827491069
fix(error): Consistently respect possible values order
...
We respected it for `--help` but not error messages.
Fixes #1549
2022-02-02 13:58:58 -06:00
Ed Page
7c79e76f2f
Merge pull request #3390 from epage/unroll
...
fix(error): Be more accurate in smart usage
2022-02-02 13:53:58 -06:00
Ed Page
06aa418fa6
fix(error): Be more accurate in smart usage
...
For some errors, we use the unroll logic to get the list of required
arguments. The usage then does the same, but without a matcher. This
was causing the lists to not match.
As a side effect, this fixed an ordering issue where we were putting the
present arg after the not-present arg. I assume its because we ended up
reporting the items twice but the first time is correctly ordered and
gets precedence.
This was split out of #3020
2022-02-02 13:30:23 -06:00
Ed Page
d318752cac
docs(derive): Expand on parse attribute
2022-02-02 10:37:47 -06:00
Ed Page
b4adda3284
Merge pull request #3385 from epage/pred
...
refactor: Clarify intent behind requires
2022-02-01 18:30:44 -06:00
Ed Page
d376865c18
refactor: Clarify intent behind requires
...
This is based on the work in #3384
2022-02-01 16:51:55 -06:00
Ed Page
f6005052a9
Merge pull request #3384 from epage/pred
...
refactor: Clarify intent of default_value_if
2022-02-01 16:50:14 -06:00
Ed Page
c0b12c7260
refactor: Clarify intent of default_value_if
...
While this doesn't help in the public API (yet), this at least clarifies
the intent in the implementation.
This is building towards #3020 .
2022-02-01 16:38:05 -06:00
Ed Page
dc035de409
chore: Release
2022-02-01 16:11:53 -06:00
Ed Page
6fa8113168
docs: Update changelog
2022-02-01 16:10:44 -06:00
Ed Page
8e807c2043
Merge pull request #3382 from epage/matches
...
feat(parser): Check if args were present
2022-02-01 16:06:59 -06:00
Ed Page
50a58e98eb
feat(parser): Check if args were present
...
In clap2, `ArgMatches.args` was public but hidden. We made it private
in clap3, giving us more implementation flexibility but many people
relied on it, like to short-circuit defaulting, providing their own
`ArgRequiredElseHelp`, etc.
The main problem was how to expose this
- If we think of `ArgMatches` as a container (a DAG), should we have an
`is_empty` and what all is included in that, like subcommands?
- If we focus on only args, what term how do we refer to this to convey
the right intent?
In the end, I realized that this aligns most with our existing
`is_present` check and reporting if args are present fits the best
within the existing API.
I looked into also exposing iterating over the args (`present_arg_ids`)
but we have no way to expose the Id. The Id is currently private and if
we made it public, it can't be used to access any arg because it can't
implement `Key`.
This supersedes #3265
2022-02-01 15:52:21 -06:00
Ed Page
8efee8a671
Merge pull request #3381 from epage/parser
...
refactor: Minor progress on reducing Parser's visibility
2022-02-01 14:21:09 -06:00
Ed Page
3722270e47
style: Clippy
2022-02-01 13:56:45 -06:00
Ed Page
c638330e85
refactor: Reduce what Parser visibility we can
2022-02-01 13:44:55 -06:00
Ed Page
05f8151d3d
fix(usage): Track all required
2022-02-01 13:38:23 -06:00
