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

Weird syntax highlighting in Rust #6848

Open
A-Walrus opened this issue Apr 22, 2023 · 1 comment
Open

Weird syntax highlighting in Rust #6848

A-Walrus opened this issue Apr 22, 2023 · 1 comment
Labels
A-tree-sitter Area: Tree-sitter C-bug Category: This is a bug upstream

Comments

@A-Walrus
Copy link
Contributor

Summary

Looking at some code from rust-analyzer:config.rs.
Results in some strange syntax highlighting within the config_data! macro:
Screenshot from 2023-04-22 15-39-05

Not sure if it counts as a bug since the code inside the macro is not actually valid rust syntax, but thought I'd file this anyway just in case 🤷‍♂️.

For reference this is what it looks like in vscode:
image
Also wrong, but in a different way 😆

Reproduction Steps

I tried this:

  1. hx config.rs

I expected this to happen:
Text inside quotes is colored as such.
Instead, this happened:
Some text is colored incorrectly

Helix log

No response

Platform

Linux

Terminal Emulator

kgx (Gnome Console)

Helix Version

helix 23.03

@A-Walrus A-Walrus added the C-bug Category: This is a bug label Apr 22, 2023
@pascalkuthe
Copy link
Member

pascalkuthe commented Apr 22, 2023

Very strange. You don't show it in your screenshot but the highlighting just stops working after a certain point altogether. This looks a lot like #6509 but I tried increasing that limit and event entirely removing it from the codebase and it doesn't change anything. Some parts of this are due to a bug in the rust grammar I suspect but some things here a super weird.

for example for "0" the 0 gets highlighted as 0 event tough even as a lexical token it's a string literal. However tree-sitter-scopes and tree-sitter-subtree actually say it's a string_literal. There are some suspicious token_tree captures showing up tough so maybe they are taking precedence somehow? Another weird thing is that the " get their own token trees. I think they probably need to specially handle string literals inside the scanner to avoid that?

Trying it out a similar issue seems to occur in nvim s oit's probably an upstream issue of some sort

@kirawi kirawi added A-tree-sitter Area: Tree-sitter A-helix-term Area: Helix term improvements and removed A-helix-term Area: Helix term improvements labels Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tree-sitter Area: Tree-sitter C-bug Category: This is a bug upstream
Projects
None yet
Development

No branches or pull requests

3 participants