search

helixbass / tree-sitter-grep

The Unlicense
4 stars 1 forks source link

Macro contents #45

Closed helixbass closed 1 year ago

helixbass commented 1 year ago

In this PR:

To test: If you run a query for eg (call_expression) @whatever against a file that contains vec![call_something()] it should match the call_something()

Based on sort-matches

helixbass commented 1 year ago

Do you know why this isn't already how the grammar works?

Per eg this comment/the test case that it's attached to since you can pass arbitrary sequences of Rust tokens or whatever to macro invocations this approach will give you (soft) parse errors if you do that

But in practice at least for [...]/(...)-style macro invocations you're almost always passing a sequence of expressions and so at least for use cases like tree-sitter-grep it seems far preferable to attempt to parse them as such. Seems like for tree-sitter-grep there is very little downside to doing so (and if there were in fact situations where people wanted to query against macro invocation contents "as token trees" then I'd think that could be "opt-in"-able)

Also worth noting that per this comment/code there is an "injection" mechanism that the existing grammar exposes which basically specifies that the contents of macro invocations can/should be re-parsed as Rust code but as far as I can tell that mechanism is only available in the context of the tree_sitter_highlight library which we're not using (and I don't think could be using at least in its current form for our use case)