Always specify a valid constant for Symbol kind #3596
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
Ruby-lsp defines the method
kind_for_entry
which maps entry types from RubyIndexer to SymbolKind constants as defined in the LSP specification. Zed expects the JSONRPC results to strictly match the protocol specificaion and when they don't it will reject the whole response. Becausekind_for_entry
did not map every RubyIndexer entry type to a SymbolKind constant, often results would be sent back to the client where the value ofkind
wasnull
. Since the LSP protocol specification defines SchemaKind as an integer enum, this means the results don't strictly match the specification and the end result was that in almost all cases I was getting no results for project symbols even though I could see the results in the Zed LSP message traces.Implementation
This PR adds a default SymbolKind value of
NULL
for unknown RubyIndexer entry classes, which will allow results to always match the protocol specification. Ideally every RubyIndexer entry class is mapped to a SymbolKind enum value, but I don't have enough experience with the LSP specification or the Ruby-lsp project to ensure all of these cases are handled. I did find that there was one entry class,RubyIndexer::Entry::GlobalVariable
, that seemed like it would correctly map to theVARIABLE
SymbolKind value and I added that here.I also encountered
RubyIndexer::Entry::UnresolvedMethodAlias
, but was unsure of which SymbolKind value that would map to. Because this class is not defined inkind_of_entry
, it will get the default SymbolKind ofNULL
. In Zed this is handled as a valid value, but the result is discarded and not displayed in the Project Symbols dialog. I have not tested how other IDEs handle theNULL
enum value, but it does conform to the specification, so it should be valid.Automated Tests
I didn't spend enough time with the codebase to understand how to add tests. If there is a basic example that I can modify to get coverage and ensure no regressions for this and someone can point me to it, I will gladly add a test.
Manual Tests
I verified these changes worked using the Zed LSP debug logs and was able to see the expected symbols in the Project Symbols dialog.