-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] Fix range filtering for tokens starting at the end of the requested range #21193
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
Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
b6ec0b2 to
b3dc5ea
Compare
Fix semantic tokens to exclude ranges that only touch (are empty) when filtering by range. Previously, ranges that touched the filter range but were empty were incorrectly included. This ensures that empty ranges at range boundaries are properly filtered out.
b3dc5ea to
cc54de8
Compare
sharkdp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
| " | ||
| x = 1 | ||
| y = 2 | ||
| z = 3<CURSOR> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: I found the <CURSOR> here distracting, as I initially thought it would somehow influence or determine the target range. Can it be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that CURSOR is ony confusing here and that semantic tokens should probably not use the cursor infrastructure to begin with. But I'd rather clean this up in a separate PR
Co-authored-by: David Peter <sharkdp@users.noreply.github.com>
Summary
This PR fixes an issue where the semantic token provider returned tokens that
started at the end offset of the selected range. That is, the
token and requested range intersect, but the intersecting range is empty.
This isn't an issue for most documents because the only outcome is tha the server
sends one additional token to the client. However, this is an issue for notebooks
where the response can only contain tokens that all belong to the same cell. Sending one extra token can then have the effect of sending the first token of the next cell,
which isn't allowed.
Test Plan
Added test. My in draft notebook PR no longer panics during semantic syntax highlighting