-
-
Notifications
You must be signed in to change notification settings - Fork 788
refactor(parser): Remove Lexer peeking for modifiers #11228
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
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
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.
Pull Request Overview
Refactors the parser’s modifier lookahead logic by replacing non-destructive peek calls with direct token consumption and checks.
- Replaces
peek_kind() == Kind::Enumwithbump_any()followed byat(Kind::Enum) - Replaces
peek_at(Kind::Enum)withbump_any()followed byat(Kind::Enum)
Comments suppressed due to low confidence (2)
crates/oxc_parser/src/modifiers.rs:321
- Calling
bump_any()in a lookahead predicate mutates parser state unexpectedly. Consider usingpeek_at(Kind::Enum)or snapshotting/restoring parser position to avoid side-effects.
Kind::Const => { self.bump_any(); self.at(Kind::Enum) },
crates/oxc_parser/src/modifiers.rs:457
- This replacement also consumes the
Consttoken during a lookahead. To preserve parser state, revert to a non-destructive peek or implement position rewind after consuming.
Kind::Const => { self.bump_any(); self.at(Kind::Enum) },
CodSpeed Instrumentation Performance ReportMerging #11228 will not alter performanceComparing Summary
|
Merge activity
|
Part of #11194 NOTE: In TypeScript parser.ts, `next_token_can_follow_modifier` seems to be the only place to handle these checks. https://github.com/microsoft/TypeScript/blob/b504a1eed45e35b5f54694a1e0a09f35d0a5663c/src/compiler/parser.ts#L2765 But we have two places, may revisit it later.
a91ca36 to
07e6ae0
Compare
Part of #11194
NOTE: In TypeScript parser.ts,
next_token_can_follow_modifierseems to be the only place to handle these checks.https://github.com/microsoft/TypeScript/blob/b504a1eed45e35b5f54694a1e0a09f35d0a5663c/src/compiler/parser.ts#L2765
But we have two places, may revisit it later.