Widen Highlights root range to covering element #7505
Conversation
|
Hm, actually this is probably the wrong approach since we might highlight the entire file again now if the covering_element is solely the source file. I think this https://github.com/rust-analyzer/rust-analyzer/blob/1a59f75cdaa730c16a694a4294eccf6dfe6fe0ad/crates/ide/src/syntax_highlighting.rs#L101-L104 might be our problem actually. This of course can let ranges pass that aren't fully contained in the root text range which then potentially fails the assertion in https://github.com/rust-analyzer/rust-analyzer/blob/1a59f75cdaa730c16a694a4294eccf6dfe6fe0ad/crates/ide/src/syntax_highlighting/highlights.rs#L41-L42 later on. |
hehe, I remember tracing the same trail of thought a while back ) |
|
I think we might want to use two different ranges here? The |
|
Good point, that should work 👍 |
Veykril
changed the title
|
bors r+ |
There have been a few issues about/containing spurious syntax highlighting panics, which all seem to come from the
rust_analyzer::handlers::handle_semantic_tokens_rangerequest, which I believe this to be the cause of as the text range we want to highlight here is currently potentially smaller than that of the covering element, so we might highlight something that is inside the covering element, but outside of the text range we wish to highlight causing the assert to fail.Unfortunately this isn't really easy to test since I have yet to find a reproducible cause(#7504 doesn't work for me cause I can't seem to checkout the given commit).
See #7504, #7298, #7299 and #7416, all of those contain an assertion failure in syntax highlighting, but only in the range request.