-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor #1976
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only early review. I will finish the full review once my 2 comments are addressed.
e7125a4
to
49b5cff
Compare
Something is bugging me about this PR and I can't exactly pinpoint what it is. Which is leading me to procrastinate on reviewing this. 😞 |
ping @pksunkara This PR is essentially a blocker for any other change to the error facility because it spans over almost thousand of lines of code over there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error::cause and Error::info should not be removed. People should have the option to use clap for other kind of stuff too. cause
should have plain error message and info
should have programmable error information.
I understand the concern about bloat, but we can always hide these if terminal-only
(or other appropriately named) feature flag is enabled. But let's decide on that later though separate from this PR.
It's not just about bloat, it's about feature creep. This is a golden opportunity to prune unused and redundant stuff, would be a real shame to miss it. Actually, this talk was the reason I removed the fields in the first place - I saw some useless code and wanted to trigger the discussion around it in hope somebody would come with a compelling reason not to remove it. Your argument is basically "let's leave it just in case". Did you ever use them? Can you give an example (some code from a real project, not a hello-world)? My arguments:
|
|
That piece gives me strong impression that you're mistaking The As I noticed earlier, I accept your reasoning for |
@CreepySkeleton Since we have the luxury to change stuff. Can we enable colored help by default? It stays hidden for quite a few crates that depends on clap, I have sent pull requests to some of them and they were surprised by this feature. |
Colored help |
Yes, the feature is on by default. IIRC even in 2.0 but I mean By the way, I have a comment above that you probably missed. |
@pickfire Could you please create a separate issue about coloring? For the record, I agree. The |
a9f6bde
to
ca9f300
Compare
} | ||
|
||
pub(crate) fn value_validation( | ||
arg: Option<&Arg>, | ||
err: &str, | ||
arg: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not &Arg? Why is val
and err
not &str
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we don't always have the Arg
, like in value_of_t
.
other: Option<O>, | ||
usage: U, | ||
other: Option<String>, | ||
usage: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not &str
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because what we need here is String
, not &str
. This way the caller can decide how to form the string and reuse the already formed String
without reallocation on our part. In fact, the caller has String
most of the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was asking because the usage
parameter in all the other errors below has &str
but this one was different. I just wanted to confirm that it was intentional since it's not consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was going to make the other methods to use String
too (I have some ongoing work done locally), but decided to postpone it as quite irrelevant (PR is already larger than necessary). Do you want it in this PR or as a followup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's only &str
to String and such minor stuff, you can add a new commit to this PR. We will squash after I review and approve the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, can you please squash the commits once the PR is ready. I don't mind if it's just one large commit.
ca9f300
to
0b213d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You misrebased the tests/help.rs file.
Your tests are failing because new stable is released. I fixed the UI tests in #2114 |
0b213d8
to
510708f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please squash now?
Once squashed, you can do |
510708f
to
5020333
Compare
bors r=pksunkara |
Build succeeded:
|
Refactor coloring/help/errors facility.
Improvements
Creation of of
clap::Error
is now completely separate from actual emitting. It cannot fail anymore.Significant code bloat decrease:
Before
After
No more our own unicorn reimplementations of
str::split
. I consider this a huge improvement.Changes to public API
App::write_[long_]version
is replaced with render version. It was necessary in order to simplify some code. I found that these methods are very rarely used, and what those people really needed wasString
.Actually, in light of
App::get[_long]_version
, I think we could just remove it. @pksunkara Any objections?Error::cause
andError::info
fields are removed. I've never seen them used in practice, and they are responsible for about10 KiB
of code bloat.print_help*
andwrite_help*
now returnio::Result
instead ofclap::Result
. There's no point to convert them to clap errors.Performance regression
I haven't done proper benchmarking yet, but I expect certain regression in error/help rendering. I suppose the regression is negligible because printing is slow enough on it's own, but I'm open to continue working on improving it.