perf(parser): fast path for no syntax errors when checking modifiers#20748
Merged
graphite-app[bot] merged 1 commit intomainfrom Mar 29, 2026
Conversation
This was referenced Mar 25, 2026
This was referenced Mar 25, 2026
Member
Author
Merging this PR will not alter performance
Comparing Footnotes
|
d6ce961 to
01e74d8
Compare
This was referenced Mar 25, 2026
01e74d8 to
85855c0
Compare
c0f2445 to
aac33f9
Compare
85855c0 to
d457c11
Compare
d457c11 to
51e6a42
Compare
aac33f9 to
4e8b817
Compare
51e6a42 to
dbffd43
Compare
8b10406 to
b26e94c
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Improves parser modifier validation performance by adding a fast-path check that avoids the branch-heavy error-construction logic in the common (no syntax errors) case.
Changes:
- Refactors
check_modifierto first run a fast legality check (is_illegal_modifier) and only fall back to error construction when needed. - Adds a compile-time-generated lookup table to decide illegal modifier ordering via a single table lookup + bitset intersection.
- Adds a unit test to ensure
is_illegal_modifierstays consistent withillegal_modifier_error.
548a6ba to
1e19687
Compare
This was referenced Mar 28, 2026
Merged
camc314
approved these changes
Mar 29, 2026
Contributor
Merge activity
|
…20748) `check_modifier` contained a large chunk of code with nested matches - lots of branches, all to handle cases which should never happen (syntax errors). Instead, do a fast check for validity using only a couple of operations and a small lookup table. Only if that fast check fails, hand over to a 2nd function `illegal_modifier_error` which does the slow work of figuring out what error to raise and raising it. In normal operation, that path should never be taken, so mark it `#[cold]` and `#[inline(never)]`. This also replaces an unpredictable branch with a very predictable one. Small perf improvement on some parser benchmarks (+0.2%).
1e19687 to
1f57448
Compare
graphite-app bot
pushed a commit
that referenced
this pull request
Mar 29, 2026
`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.
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.

check_modifiercontained a large chunk of code with nested matches - lots of branches, all to handle cases which should never happen (syntax errors).Instead, do a fast check for validity using only a couple of operations and a small lookup table. Only if that fast check fails, hand over to a 2nd function
illegal_modifier_errorwhich does the slow work of figuring out what error to raise and raising it. In normal operation, that path should never be taken, so mark it#[cold]and#[inline(never)].This also replaces an unpredictable branch with a very predictable one.
Small perf improvement on some parser benchmarks (+0.2%).