refactor(parser): shorten code handling illegal modifiers#20781
Merged
graphite-app[bot] merged 1 commit intomainfrom Mar 29, 2026
Merged
Conversation
Member
Author
This was referenced Mar 26, 2026
This was referenced Mar 26, 2026
Merging this PR will not alter performance
Comparing Footnotes
|
Contributor
There was a problem hiding this comment.
Pull request overview
Refactors the parser’s illegal_modifier_error logic to reduce repetition and improve readability, with a corresponding snapshot update for the one changed diagnostic message.
Changes:
- Added
ModifierKinds::intersectionhelper for bitset operations. - Rewrote
illegal_modifier_errorto compute illegal-preceding sets and emit diagnostics more compactly. - Updated the Babel parser snapshot to reflect the updated TS1029 message in one fixture.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tasks/coverage/snapshots/parser_babel.snap | Updates expected TS1029 diagnostic text for one invalid-modifier-order fixture. |
| crates/oxc_parser/src/modifiers.rs | Refactors illegal modifier error generation and adds a ModifierKinds intersection helper. |
b26e94c to
548a6ba
Compare
1bfb403 to
d924cd6
Compare
548a6ba to
1e19687
Compare
d924cd6 to
bdb5960
Compare
This was referenced Mar 28, 2026
Merged
This was referenced Mar 28, 2026
camc314
approved these changes
Mar 29, 2026
Contributor
Merge activity
|
bdb5960 to
60b3c4e
Compare
`illegal_modifier_error` contained a large amount of repetitious code, and was hard to read. Convert it to a shorter version which makes the logic clearer, reusing the lookup table introduced in #20748. This change also reduces the size of generated code considerably and makes it faster, but #20748 moved this code onto a cold path, so that doesn't really matter. The main benefit is greater readability. One test case produces a slightly different error after this change. ```ts class D extends B { constructor(override readonly public foo: string) {} } ``` ```diff - TS(1029): 'public' modifier must precede 'override' modifier. + TS(1029): 'public' modifier must precede 'readonly' modifier. ``` Both errors are correct, and which gets flagged was arbitrary before - it wasn't dependent on the order of modifiers in the source code, only the order of `if` branches in `illegal_modifier_error`. So IMO this change isn't important - it's just a *different* arbitrary order now.
60b3c4e to
2529cfb
Compare
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
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.

illegal_modifier_errorcontained a large amount of repetitious code, and was hard to read. Convert it to a shorter version which makes the logic clearer, reusing the lookup table introduced in #20748.This change also reduces the size of generated code considerably and makes it faster, but #20748 moved this code onto a cold path, so that doesn't really matter. The main benefit is greater readability.
One test case produces a slightly different error after this change.
Both errors are correct, and which gets flagged was arbitrary before - it wasn't dependent on the order of modifiers in the source code, only the order of
ifbranches inillegal_modifier_error. So IMO this change isn't important - it's just a different arbitrary order now.