-
Notifications
You must be signed in to change notification settings - Fork 358
aaron/parser5 #2971
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
base: canary
Are you sure you want to change the base?
aaron/parser5 #2971
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Merging this PR will improve performance by 10.72%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | WallTime | bench_incremental_rename_type |
243.8 µs | 220.2 µs | +10.72% |
Comparing aaron/parser5 (81efa88) with canary (70dc924)
Footnotes
-
35 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
| first_path: path.clone(), | ||
| second: existing.span, | ||
| second_path: existing.path.clone(), | ||
| }); |
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.
Swapped spans produce semantically incorrect duplicate error labels
Medium Severity
In the first error emitted when a duplicate is detected, the first and second fields are swapped. The error format uses second for the "redefined here" label and first for the "first defined in..." label. The code sets first: span (the duplicate) and second: existing.span (the original), causing the original definition to be labeled as "redefined here" and the duplicate to be labeled as "first defined" - semantically backwards. The test expectations confirm this: line 1 (original) shows "redefined here" while line 5 (duplicate) shows "first defined".
| self.error_unexpected_token("'>'".to_string()); | ||
| false | ||
| } | ||
| } |
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.
Stale pending_greaters state corrupts subsequent generic parsing
Medium Severity
The pending_greaters counter tracks pending > tokens from split >> tokens for nested generics. However, it's never reset at type or field boundaries. If a user writes a malformed type like map<K, V>> (with an extra >), the >> is consumed and pending_greaters is set to 1. Since there's no outer generic to consume the pending count, it persists. When parsing the next generic type (e.g., in another field), expect_greater() sees pending_greaters > 0, decrements it, and returns true without consuming the actual > token. This leaves the > in the token stream, causing cascading parse errors.
Note
Improves correctness and DX across parsing and HIR diagnostics.
>>viaexpect_greater; add recovery for invalid blocks (classs Foo { ... }) and invalid type aliases (typpe Name = ...); better tuple/type-expr recovery with clear messages (e.g., path identifiers in types); detect old-style function syntax and emit a single helpful error; integrated in top-level parsing flows.get_item_name_span) and tracks item kind; emits an error for both the first definition and each duplicate with correct locations; updated tests/snapshots and added a focused repro.Written by Cursor Bugbot for commit 81efa88. This will update automatically on new commits. Configure here.