Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add missing rust query #122

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

Danielkonge
Copy link
Contributor

@Danielkonge Danielkonge commented Jun 8, 2024

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.

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>.
@HiPhish
Copy link
Owner

HiPhish commented Jul 7, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Danielkonge commented Jul 10, 2024

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
Copy link
Owner

HiPhish commented Jul 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants