You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! I am attempting to use tree-sitter as the initial parser for a compiler using rust bindings to the grammar I have generated.
When it comes to translating the AST I realized that I either have to use strings to identify the nodes or manually keep some sort of enum where I track the kinds. I have considered trying to use the tree-sitter api itself or bindgen to attempt this, but I realize there isn't really a good stable number that could be used for such an enum after looking at #2056.
My concern is that if I manually implement the mapping to an enum, the numbers or strings used for comparison will go out of sync as I make grammar changes. I understand that a mapping will still need to be made between the nodekind ids and the tags in my intermediate representation, but if the nodekind(id)s can change out from under me as I add features, it feels like shaky footing to work from.
It feels like this could or should automatically be generated during the build.rs of the tree-sitter-[my-lang] crate. This way there will be compile errors if things change in such a way that the consuming program's mapping isn't correct anymore.
The text was updated successfully, but these errors were encountered:
glfmn
changed the title
Generate enum for field and node names
Generate enum for field and node kinds
Jul 12, 2023
Hello! I am attempting to use tree-sitter as the initial parser for a compiler using rust bindings to the grammar I have generated.
When it comes to translating the AST I realized that I either have to use strings to identify the nodes or manually keep some sort of
enum
where I track the kinds. I have considered trying to use the tree-sitter api itself or bindgen to attempt this, but I realize there isn't really a good stable number that could be used for such an enum after looking at #2056.My concern is that if I manually implement the mapping to an enum, the numbers or strings used for comparison will go out of sync as I make grammar changes. I understand that a mapping will still need to be made between the nodekind ids and the tags in my intermediate representation, but if the nodekind(id)s can change out from under me as I add features, it feels like shaky footing to work from.
It feels like this could or should automatically be generated during the build.rs of the
tree-sitter-[my-lang]
crate. This way there will be compile errors if things change in such a way that the consuming program's mapping isn't correct anymore.The text was updated successfully, but these errors were encountered: