fix(derive)!: Don't Panic, Error #2943
Conversation
This gives us room to add extra context later.
While `App::error` is what most people will need, `clap_derive` needs to handle when the site raising the error doesn't have access to the `App` and needs to defer that to later.
If the user prints a raw error, it may include color even if the user turned it off at runtime. Now we'll be more conservative and never show color for raw errors.
The derive is generating `Error::raw` (from scratch or by converting existing erors) and then the inherent `Parser` methods format them. Fixes clap-rs#2255
|
Going ahead with this as I've got some more branches blocked on this bors r+ |
|
Build succeeded: |
|
Also, needs tests. |
With each change, I have to balance how much more work I can do on top of it vs sit idle. With higher chances of conflicts (like this PR), the chance of me sitting idle is higher so I can be responsive to change. A counter-balance to keep things progressing is lower risk changes (e.g. things that aren't direction setting like #2617), since I can just as easily respond to review feedback in distinct PRs as not and they will most likely have a lower chance of conflicts. |
This is to help verify behavior added in clap-rs#2943. We separated the error raising site from the error formatting site and this verifies that the formatting actually happens.
If the user prints a raw error, it may include color even if the user turned it off at runtime. Now we'll be more conservative and never show color for raw errors. This is a follow up to clap-rs#2943; apparently I had missed some cases.
|
Now that it's possible to produce validation errors while parsing the values from |
|
The error reporting in this PR is much more crude than what the validators can perform. #2683 will remove the double parse generally. |
This switches all of our
unwrapandexpects in the generated code to pass errors up.#2890 exposed
App::errorto users. While this PR was the encouragement for it, I felt it was a worthwhile addition to the API anyways. For most users, it will be sufficient but unfortunately not for the derive. We don't have access to theAppat the error site. We need to pass up the error in "raw" form and then format it right at the end. To accomplish this, we are now tracking whether the error is formatted or not and expose to usersError::rawto create an unformatted error andError::formatto then format it.Parserinherent methods were updated to do this formatting for the user.To abstract the difference in formatting, I used
Cow. To supportCow, I needed to make some internal typesCloneable.Fixes #2255