Decide whether K"parens" should be visible to SyntaxNode
#239
Comments
Possible fix for #239: * Add a `head` field to `SyntaxNode` to separate it from `GreenNode` * When a `K"parens"` node is encountered in the green tree, replace it with its child. * However, have the replacement point to the parens `GreenNode` so we can still observe parentheses This turns out to work, but is awkward. It's especially awkward/surprising for `sourcetext`, as we have things like ```julia julia> kind(parsestmt(SyntaxNode, "(10)")) K"Integer" julia> sourcetext(parsestmt(SyntaxNode, "(10)")) "(10)" ``` We could fix `sourcetext()` to avoid this inconsistency at the cost of traversing the raw tree dynamically. But then do we also need to change `range()`?
|
Ugh this is pretty awkward no matter which way you look at it. Diverging the Also when I tried to fix this in #265 I found that approach (make SyntaxNode point to its outermost GreenNode parent of type `K"parens") quite awkward as described there. Another alternative approach is to have The irritation there is that we occasionally need in Hmm. Maybe it's time to convert directly from |
As of #222 etc we have a parse node for grouping parentheses. This is extremely useful for tooling and has allowed several parsing difficulties to be solved neatly.
But it's pretty inconvenient when using
SyntaxNodein a way that few other tree nodes are - parentheses are permitted in many unusual situations in the reference parser, and often treated as completely invisible to the parser.Also
SyntaxNodeis AST-like, but grouping parens are arguably syntax trivia and shouldn't be in the AST anyway.So maybe we should include parens only in the green tree, but elide them when converting to
SyntaxNode.The text was updated successfully, but these errors were encountered: