search

gdamore / tree-sitter-d

D Grammar for Tree Sitter
MIT License
41 stars 7 forks source link

Member function properties are put at different levels in the parse tree depending on whether the are placed before or after the function header #37

Closed nordlow closed 1 month ago

nordlow commented 3 months ago

Currently @property is put at different depths in parse tree for the cases

1.

struct S { @property hash_t toHash() const scope; }

2.

struct S { hash_t toHash() const scope @property; }

. Would it be possible for the grammar to be changed so that @property is grouped under the toHash-declaration in case 1?

It might be that this applies to non-member function properties aswell.

gdamore commented 3 months ago

What you are after is semantic processing and not something we can really do in the syntax tree.

• Garrett On Jul 30, 2024 at 3:41 AM -0700, Per Nordlöw @.***>, wrote:

Currently @property is put at different levels in parse tree for the cases

1.

struct S { @property hash_t toHash() const scope; }

2.

struct S { hash_t toHash() const scope @property; } . Would it be possible for the grammar to be changed to that @property is grouped under the function declaration in case 2? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

nordlow commented 3 months ago

What you are after is semantic processing and not something we can really do in the syntax tree. • Garrett

Are you saying this source to concrete syntax tree mapping shouldn't or cannot be expressed in a tree-sitter grammer?

gdamore commented 1 month ago

I'm saying it might not be possible. The grammar has a number of ambiguities in it that can only be resolved with semantic understanding of context. I'll look to see if this is the case here or not.

gdamore commented 1 month ago

Yes, its an ambiguity in the grammar.

Probably this could be improved. The issue is that there are different kinds of declarations, and we allow attributes in front of any declaration, and that happens outside of the generic _declaration2 node type.

Fixing this should be possible, but it will likely grow the grammar a bit more -- both in terms of the number of places I have to decorate this, and and in terms of the size of the generated grammar.