Open
Conversation
specifying a `transform` function.
not parsed as explicit rules or extractable.
within the grammar module.
commit incoming to do the same with `leaf`
like rules in them: * Can now provide text directly * Can now provide a `re` or `pattern` function to specify a function * Can now specify `choice` directly * Can now specify `seq` directly * Can now specify `optional` directly
the original implementation, we will need to allow TsInput to handle references to other rules.
Remove `dbg!` calls
* Can transform on a node directly for more complex parsing * Pass along `Point` for better span handling * Begin experimenting with mapping functions...
into a common grammar.
`#[extras(...)]` on the `#[language]` rule.
that to extract information. This allows for the grammar to be flatten significantly by not requiring every field be its own rule.
Member
|
Appreciate all of this work and interest on rust-sitter, pinging @shadaj to see how much of this we could upstream (eventually) |
Author
I forgot I opened this pull request - hopefully you weren't getting spammed with every commit. I have since hacked on this project a lot - I imagine it is mostly unrecognizable at this point. If you would like to review or walk through it, let me know. Otherwise, it was my intention to maintain a separate fork. |
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.
Hi,
At Otonoma we needed
rust_sitterfor internal use, however, in the process of writing a grammar we decided to rewrite portions of it for ease of use. Many of these changes are stylistic (and significantly breaking), so I don't expect you to merge this pull request, we intend to maintain our fork separately.I mostly wanted to make this community aware of the changes we were making in our fork - some of the features would fit back in nicely, others maybe not.
Here is a brief summary of the changes:
#[rust_sitter::grammar(...)]in favor of explicitderive(Rule)on types.Extracton various additional base types. In particular, numeric types will defer toFromStr,Stringwill extract directly, tuples can be extract.leafextraction, so you can write a leaf like this:build.rsexecution, but are printed more nicely, so you get the classic "Unresolved conflict for symbol sequence: ..." error message when applicable.Let me know what you think and thank you for the project