refactor(parser): simplify arrow start tracking#17838
Merged
nicolo-ribaudo merged 5 commits intobabel:mainfrom Mar 2, 2026
Merged
refactor(parser): simplify arrow start tracking#17838nicolo-ribaudo merged 5 commits intobabel:mainfrom
nicolo-ribaudo merged 5 commits intobabel:mainfrom
Conversation
Collaborator
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/61080 |
Member
|
The test262 failures seem to be related. Example: var C = class extends () => {} {
}; |
|
commit: |
Contributor
Author
Yes, I am working on a fix and I just found another Babel parser bug affecting both 7 and 8. We forgot to check the typeof async x => {}
0 + async x => {}
class C extends async x => {} {}
// decorator-legacy
var C = class { @async x => {} method () {} }I will work on a bugfix first and will adapt to the bugfix in this PR. |
JLHwung
force-pushed
the
simplify-arrow-start-tracking
branch
from
a408901 to
7c1e995
Compare
JLHwung
force-pushed
the
simplify-arrow-start-tracking
branch
from
7c1e995 to
f1d72ce
Compare
liuxingbaoyu
approved these changes
Feb 27, 2026
Co-authored-by: liuxingbaoyu <[email protected]>
nicolo-ribaudo
added
PR: Internal (next major) 🏠
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In this PR we simplify the tokenizer state
potentialArrowAt(backed by 4-byte SMI in V8 in most cases1) to a boolean bitcanStartArrow. The boolean bit is set totruein the start ofparseMaybeAssignandFSharpPipelinebodyand set tofalsewhenThe reason we have to track
canStartArrowis that arrow function can only be formed in the start of the AssignmentExpression production. However because of its ambiguity with ParenthesizedExpression, a production that we handle inparseExprAtom, we can not know if this is an arrow function until a=>is seen after a ParenthesizedExpression inparseExprAtom. Therefore, we should setcanStartArrowtofalseto any sub production withinparseMaybeAssignthat satisfies the following conditions:parseExprAtomwithout callingparseMaybeAssignfirst.We also added more test cases where an arrow function is formed in the non-leading positions of an assignment expression.
Context: This PR is inspired from the F# pipeline body parsing, where we unconditionally set
potentialArrowAtwithout ever testing if it starts with a left paren or an identifier like we did inmaybeAssign. At first I thought there may be a potential bug but I cannot construct an edge case that would otherwise require the token test. Then I realized the detection is redundant, there will be no side effect ifpotentialArrowAtis recorded in for example, function expression as long as it still records the position of the start of the current assignment expression. And that ultimately leads to the simplification of the tokenizer state to a boolean flag.Footnotes
Unless the code length is over 2**31 or the parser is invoked with a huge
startIndexoption. ↩