-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add CST labels to EBNF #976
Add CST labels to EBNF #976
Conversation
|
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.
Great work. LGTM!
52fcc10
to
8ab4b58
Compare
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.
Thanks for the refactoring. Only one tiny suggestion left.
a2fb1b7
to
e6a72c0
Compare
Missing some built-in labels, such as those internal to operators and items and separators.
Because they are not direct children of Topic, they were being omitted from the output when building the language spec.
This allows labelling Separated, which was the remaining grammar Item that needed it.
Co-authored-by: Omar Tawfik <[email protected]>
e6a72c0
to
4ca53ee
Compare
Spin off of #976 Moves the `BuiltInLabel` enum from the parser generator into the language definition and remove duplication in the `kinds` template.
…Foundation#1002) Part of NomicFoundation#638 Follow-up to NomicFoundation#991 Pretty straightforward: instead of visiting the previously built v1 definition structure, we defer to `Language::collect_breaking_changes` as the definitions overlap - the breaking changes are defined as versions in which the syntax items may be evaluated differently, which means that these are exactly the versions that will be referenced for the conditional syntax item evaluation in the parser/lexer. Refactor `BuiltInLabel` to avoid duplication (NomicFoundation#992) Spin off of NomicFoundation#976 Moves the `BuiltInLabel` enum from the parser generator into the language definition and remove duplication in the `kinds` template. add wit generating wit and glue stub adaptors, wit feature flag glue macros remove wit_bindgen fix wit gen paths add wit-bindgen export the kinds pub export macro for wit improve export macro world => slang fully implement glue convert query matches refactor ffi glue macros refactor wit variant rather than enum back to enum
…Foundation#1002) Part of NomicFoundation#638 Follow-up to NomicFoundation#991 Pretty straightforward: instead of visiting the previously built v1 definition structure, we defer to `Language::collect_breaking_changes` as the definitions overlap - the breaking changes are defined as versions in which the syntax items may be evaluated differently, which means that these are exactly the versions that will be referenced for the conditional syntax item evaluation in the parser/lexer. Refactor `BuiltInLabel` to avoid duplication (NomicFoundation#992) Spin off of NomicFoundation#976 Moves the `BuiltInLabel` enum from the parser generator into the language definition and remove duplication in the `kinds` template. add wit generating wit and glue stub adaptors, wit feature flag glue macros remove wit_bindgen fix wit gen paths add wit-bindgen export the kinds pub export macro for wit improve export macro world => slang fully implement glue convert query matches refactor ffi glue macros refactor wit variant rather than enum back to enum
Closes #916
Closes #917
The changes add the corresponding CST labels to the generated EBNF grammar representation, via the use of a leading comment before the appropriate references (which represent the nodes in the CST).
This PR also adds the
PrecedenceExpression
visible in the generated EBNF, fixing #917. Since they are not direct children of theTopic
s they were being omitted from the language specification.A couple of questions/items I have doubts on:
I copied the
BuiltInLabels
enum from the grammar generator crate because it was private and not directly accessible from theebnf
crate. But I think it may make sense to move the enum into thelanguage_definition
crate? It may make it possible to remove all the duplication.A minor concern is the readability of the resulting EBNF, for sequences in particular. Adding the labels introduces noise to the spec document already. But for separated sequences, the resulting lines almost never fit into the enclosing box in the HTML, which forces horizontal scrolling.