Repository navigation
Fix O(n²) performance issue with unmatched parentheses - #324
Conversation
…iner preludes scan_matching_paren rescanned to the end of the prelude for every unmatched "(", so e.g. `@media ((((…` took ~6s at 32KB. Remember the parens left open after a failed scan so later scans starting at one of them return immediately, making the parse linear. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
| 📦 Package | 📏 Base Size | 📏 Source Size | 📈 Size Change |
|---|---|---|---|
| @projectwallace/css-parser | 43.9 kB | 44.1 kB | +156 B |
|
The Audit packages check is red, but not because of this PR. No fix exists on the base yet. A fix is either bumping Generated by Claude Code |
Summary
This PR fixes a quadratic time complexity issue in the condition parser when handling unmatched opening parentheses. Previously, the parser would rescan the same range repeatedly for each unclosed parenthesis, causing severe performance degradation on inputs with many consecutive
(characters.Key Changes
unmatched_opensSet andunmatched_opens_endto cache positions of parentheses that cannot be matched within a given range, avoiding redundant rescansopen_stackarray to track all open parenthesis positions during scanning, enabling efficient recording of unmatched opens on failure() and confirming that matched features after unclosed parentheses are still correctly parsedImplementation Details
endposition; it's invalidated when the range changeshttps://claude.ai/code/session_01HC4UoMkXyXbW2knnFrvmJ6