-
-
Notifications
You must be signed in to change notification settings - Fork 411
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
[Merged by Bors] - Reduced boilerplate code in the parser #2410
Conversation
Test262 conformance changes
|
Codecov Report
@@ Coverage Diff @@
## main #2410 +/- ##
==========================================
+ Coverage 38.41% 38.72% +0.31%
==========================================
Files 313 313
Lines 23974 23874 -100
==========================================
+ Hits 9210 9246 +36
+ Misses 14764 14628 -136
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
OrAbrupt
trait to reduce some boilerplate code in the parserThere 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.
Great changes!
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.
Looks perfect to me!
bors r+ |
This PR adds an `OrAbrupt` trait, with the `or_abrupt()` function. This function is equivalent to the previous `?.ok_or(ParseError::AbruptEnd)`, but it's cleaner. It's implemented for the parser cursor results types. It also adds an `advance()` function to the parser cursor (which might be possible to optimize further), that just advances the cursor without returning any token. This shows a clearer intent in many places where it's being used. I also used `ParseResult` in more places, since we were not using it in many places.
Pull request successfully merged into main. Build succeeded: |
This PR adds an
OrAbrupt
trait, with theor_abrupt()
function. This function is equivalent to the previous?.ok_or(ParseError::AbruptEnd)
, but it's cleaner. It's implemented for the parser cursor results types.It also adds an
advance()
function to the parser cursor (which might be possible to optimize further), that just advances the cursor without returning any token. This shows a clearer intent in many places where it's being used.I also used
ParseResult
in more places, since we were not using it in many places.