Narrow search range for tree-sitter queries

[pokey]

In #1800, we introduced a workaround for tree-sitter/tree-sitter#2484, which means that we no longer restrict the search range for our tree-sitter queries. That workaround has no impact on correctness, but could have performance implications for large files, as we get all matches and then filter them after the fact, rather than restricting to the range we care about. Once tree-sitter/tree-sitter#2484 is fixed, we'd like to reactivate our code that restricts the search range, by rolling back #1800

[josharian]

In the meantime, If the file is particularly large, it might be better to disable treesitter scopes entirely, similarly to how VS code disable syntax highlighting on massive files.

[pokey]

Fwiw we're already parsing the file; this issue is just about running the tree query, which is likely many orders of magnitude faster

[josharian]

#1889 removes some of the code that we will need to resume restricting the search tree.

[pokey]

@AndreasArvidsson while you're looking into performance stuff, fwiw it appears tree-sitter/tree-sitter#2484 is fixed so we should be able to start restricting tree-sitter query range again. I'm not sure it's urgent but figured I'd flag since you're very familiar with performance right now

[AndreasArvidsson]

@AndreasArvidsson while you're looking into performance stuff, fwiw it appears tree-sitter/tree-sitter#2484 is fixed so we should be able to start restricting tree-sitter query range again. I'm not sure it's urgent but figured I'd flag since you're very familiar with performance right now

Doesn't look like it's fixed actually. They just closed it.
I can't reproduce this issue in the playground which also uses web-tree-sitter.

I rolled back the changes and tried to run our test and they are indeed failing.

[pokey]

Strange. Possible we're on an old web-tree-sitter in vscode parse tree. I'll bump at some point and we can try again

[AndreasArvidsson]

Please do

[pokey]

Done; hopefully it works now 🤞

[AndreasArvidsson]

No go. Still 4 test that are failing. I will have a look at the position logic to make sure we haven't done anything incorrect.

[AndreasArvidsson]

Oh I think it might be our logic in getQuerySearchRange that is failing now.

Edit:

Looks like the each capture needs to be overlapping the startPosition-endPosition range. Take this example:
bbb = () => {};|

We are here matching two different captures. We have the field definition where we start our content range and we have the semicolon where we end our content range. getQuerySearchRange takes our position and extends it one character to the left and to the right so we end up with:

bbb = () => {}|;
|

That means that we are not overlapping with the field capture and the pattern is not matched

[AndreasArvidsson]

This patten does not work

(
  (field_definition
    value: (arrow_function)
  ) @namedFunction.start
  .
  ";"? @namedFunction.end
)

But this does work:

(_
  (field_definition
    value: (arrow_function)
  ) @namedFunction.start
  .
  ";"? @namedFunction.end
) 

The only difference is the inclusion of the wildcard at the top level. Without that we don't have a common ancestor for all captures.