-
Notifications
You must be signed in to change notification settings - Fork 19
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
Clean up precedence parser codegen since DSL v2 #699
Conversation
🦋 Changeset detectedLatest commit: 04a6e59 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This introduced individual rule kinds per each precedence expression and we lose the grouping rules such as BinaryExpression. Not sure how desirable they were in the first place but it seems better and easier to handle specific expressions rather than using grouping rule kinds like before.
Since it's the only place it's used and it's a small helper.
b2648f8
to
0293980
Compare
This also fixes a run-time regression introduced with duplicate operator parsers when migrating to v2. To support different associativity/models for precedence expressions across multiple versions, the parser generator now: - groups the operators by model for a given precedence expression - defines a sub-parser for (expression, model) as a choice over the operators with a given model - each of the precedence sub-parses reduces to the parent precedence expression rule kind.
This lets us completely get rid of the ProductionKind, as we support parsing every `RuleKind` now.
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.
Thank you. Left a few suggestions/questions.
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.
One question remaining about snapshot tests.
Co-authored-by: Omar Tawfik <[email protected]>
This reverts commit 0296bef.
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @nomicfoundation/[email protected] ### Minor Changes - [#699](#699) [`ddfebfe9`](ddfebfe) Thanks [@Xanewok](https://github.com/Xanewok)! - Remove `ProductionKind` in favor of `RuleKind` - [#699](#699) [`ddfebfe9`](ddfebfe) Thanks [@Xanewok](https://github.com/Xanewok)! - Allow parsing individual precedence expressions, like `ShiftExpression` - [#665](#665) [`4b5f8b46`](4b5f8b4) Thanks [@Xanewok](https://github.com/Xanewok)! - Remove the CST Visitor API in favor of the Cursor API - [#666](#666) [`0434b68c`](0434b68) Thanks [@Xanewok](https://github.com/Xanewok)! - Add `Node::unparse()` that allows to reconstruct the source code from the CST node - [#675](#675) [`daea4b7f`](daea4b7) Thanks [@OmarTawfik](https://github.com/OmarTawfik)! - rename `Cursor`'s `pathRuleNodes()` to `ancestors()` in the NodeJS API. - [#676](#676) [`b496d361`](b496d36) Thanks [@OmarTawfik](https://github.com/OmarTawfik)! - Fix NAPI `cursor` types and expose `cursor.depth`. ### Patch Changes - [#685](#685) [`b5fca94a`](b5fca94) Thanks [@Xanewok](https://github.com/Xanewok)! - `bytes` is now properly recognized as a reserved word - [#660](#660) [`97028991`](9702899) Thanks [@Xanewok](https://github.com/Xanewok)! - Drop List suffix from collection grammar rule names Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
remaining from #699
Part of #638
This PR:
PrecedenceExpression::rule_name
in favour of using the name directly for its rule/node kindFieldKind
from DSL v2 #687 (comment))ProductionKind
in favour of the now-completeRuleKind
I can split this up but since all of this is interconnected, it made sense to work on them at the same time and submit work that solves all of the aforementioned issues.