Provide constant type differentiation in semantic highlighting request #1148
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Fixes #1128 (Potentially)
This PR aims to modify the
SemanticHighlighting
class so that it can properly determine what type of constant is being referenced in a given piece of code. The details and discussion can be found in the issue, but we want syntax highlighting to know thatFoo
inFoo.new
below is referencing the classFoo
and isn't just some other constantFoo
, for example:Implementation
Following @vinistock's recommendations, I made sure an instance of
RubyIndexer::Index
is given to the request and created a variable to keep track of nesting. Additionally subscribed to events needed to keep track of this nesting.At the time of submission, the PR is incomplete, however. I wasn't able to figure out how to properly set up the index in the tests, so the lines where I call
index_single
are definitely something that needs fixing.Finally, one thing discussed in the issue is that, even if this is implemented correctly, it might be too resource intensive, so if this gets finished, benchmarks will be required
Automated Tests
Haven't added any new tests so far but only tried to modify the current test to reflect the needed changes.
Manual Tests
The issue was opened referencing neovim, so I'm not sure if this affects VS Code. However the request doesn't have this specific capability so I think it's surely possible to replicate this by opening the example file provided in the issue.