Add missing rust query

[Danielkonge]

Note that the current neovim treesitter implementation only captures anything inside a rust macro via token_tree, so we need this new query to capture <T>.

I added some examples in the test file, but the only thing the new query fixes is the line with:

vec![Generic::<u8>::new(1)]

I only just now figured out that we don't actually capture the stuff inside macros via the standard queries, we only capture things inside e.g. a vec! via token_tree.

I thought that knowing this might help fixing the highlighting in C/C++ too (see #80), but it seems that the "self-injections" don't work the same there, so I couldn't see any easy fix to the current problems there.

[HiPhish]

I don't know Rust, so I need some help here. Looking at the syntax tree of the test file I don't see any token_tree followed by < or > in Neovim 0.10. The <T> is represented as

(type_parameters
  "<"
  ">")

On a side note, I get ten errors in the syntax tree when I use :InspectTree, but none with :TSPlayground. Do you get the same? Do you have an idea of what could be going on? Maybe it's a bug in Neovim's :InspectTree implementation.

[Danielkonge]

The <, > here are usually captured by

(type_arguments
  "<"
  ">")

but that doesn't seem to work inside macros in Rust. In general, I can't get correct highlighting inside macros without token_tree. To get correct highlighting in Rust, the only solution I have found so far is using token_tree, which I think is what "marks" the macro. I am not sure why captures work in this different way in Rust (or if I am doing something wrong), but this solution was the easiest workaround I found.

I also get the ERRORs, so maybe that is what causes problems here? I haven't really looked into this in more detail since this commit fixed my issue.

[Danielkonge]

I looked into this a bit more and I think I remember why we added the other token_tree containers originally. The problem is the way rust handles macros, where it injects itself, and if we capture them as usual, then we get wrong highlighting in a couple of ways:

• Something like vec![vec![0]] would in theory highlight all [, ] in red, since they would each be a new injection, so the highlighting level would start counting from 0.
• Actually the above, and a lot of other cases too, even without nested macros, run into another problem: Since we can't provide column numbers to vim.api.nvim_buf_clear_namespace or to iter_matches/iter_captures, the current code would reset highlighting on the line when doing the innermost macro, which would remove all other highlighting on the first and last line of the macro (only the first and last line cause problems).

This is also the reason we have the parent_lang ~= lang check in the global strategy, when deciding on the update ranges. (This check should probably have included or lang ~= rust).

[HiPhish]

I have opened a new issue for the discrepancy in error reports: neovim/neovim#29726

I suggest we put this issue on hold for now until we know wheter there is a bug in Neovim or the parser, or if things really are that complicated. If there is a but we get the fix for free, and if the problem is on our end we can still solve it the hard way.