Commit graph

5076 commits

Author SHA1 Message Date
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
Ed Page
232c17ebc4 refactor(help): Decouple from parser 2022-02-01 13:23:58 -06:00
Ed Page
3cd9174f48 refactor(usage): Decouple from the parser
This is a step towards removing `pub(crate)` and for moving usage/help
out of the core clap generally.
2022-02-01 12:42:32 -06:00