-
Notifications
You must be signed in to change notification settings - Fork 51
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
Add context in name validation errors #301
Conversation
I think this is definitely worth doing. In the future we could also do similar treatment to:
(with the current and cert times) The other future improvement would be to have a more detailed
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #301 +/- ##
==========================================
+ Coverage 97.23% 97.30% +0.07%
==========================================
Files 20 20
Lines 4225 4343 +118
==========================================
+ Hits 4108 4226 +118
Misses 117 117 ☔ View full report in Codecov by Sentry. |
Good ideas! Have not implemented them yet, figure it makes sense to get this in first as a proof point and to iron out the pattern here. |
7bc8a7a
to
98d5332
Compare
a40d2ca
to
c67bd76
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.
Here's some initial feedback. Overall I think it's 👍
18dc1a0
to
1757dc0
Compare
Fixed the test failures and tacked on some refactoring. |
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.
The error context changes LGTM.
I'm a little bit nervous about the NameIterator simplification at the end w.r.t the directory_name bool change. I think it's probably OK but want to review that part of the diff with fresh eyes before I +1 the whole PR. I find the pre-existing code hard to reason about when I haven't been working in this repo recently.
If you want to pull refactoring out into a second PR to land the error improvement sooner that's OK with me too.
Is this something you're using to track your F/OSS work? FWIW the links are 404s for me as an unauthed user so I'm not sure it's useful for Asana to be putting them in the PR desc. |
Yeah, trying out Asana to track my personal tasks and its GitHub integration turned out to be more bidirectional than I thought. Will remove it. |
That sounds like a good idea! |
It's gone for now, will bring it back in a separate PR after this is merged. |
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.
Nice :-)
Will wait to see if @ctz has any more detailed feedback. |
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.
(beach review: lgtm!)
This pretty much achieves my goals and is probably workable but not quite pretty:
Copy
forError
means a semver-incompatible changealloc
vs noalloc
?I can fix test failures etc if we think this is worth doing.