Always specify a valid constant for Symbol kind

[cbisnett]

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. Because kind_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 of kind was null. 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 the VARIABLE 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 in kind_of_entry, it will get the default SymbolKind of NULL. 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 the NULL 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.

[graphite-app]

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[cbisnett]

I have signed the CLA!

[vinistock]

Thanks for the PR and the detailed explanation. Are you positive that the Null kind means "no symbol" and not nil? My original understanding of that kind is that it literally meant a null occurrence and not a missing kind.

Also, we should add the correct kinds for the index entries that are missing, so that they are displayed correctly.

What do you think about adding a unit test that will verify if all entry types have a kind? Basically, have the test index the LSP's codebase itself and then request the symbol kind for each entry, asserting that it isn't nil.

That would make it easier to ensure that we don't forget to handle all entry types.

[cbisnett]

Are you positive that the Null kind means "no symbol" and not nil? My original understanding of that kind is that it literally meant a null occurrence and not a missing kind.

No, I'm not positive that is the correct value. It was unclear to me how some of the AST types should map to LSP Symbol types. For many of the types there is probably a better mapping, but I went with NULL as the default value for when a Symbol mapping is unknown. This is effectively what exists today, but depends on how the editor handles NULL values in the JSON. Zed expects conformance to the spec and the spec says it will be an integer and does not allow for NULL. Specifying the NULL Symbol kind at least allows the output to conform to the specification allowing it to be parsed successfully by Zed.

I looked at this as a quick fix to make it conform and was thinking a follow-up PR could update the mappings. If you think it's better to do those both together and have a test for it I can see about adding that. I still think having the fallback to the Null Symbol when there is no match is good to maintain conformance.

[vinistock]

You make a fair point. I'd still like to have a test so that we can ensure every entry is mapped to a kind, but let's move forward with this for now.

There are two things we should do this in this PR though:

1. Log something so that discovering which entries are missing kinds is easier. The Null fallback will guarantee spec conformity, but not correct logic
2. Update the return type of this method. It will now always return Integer and not nilable Integer

[vinistock]

Suggested change

	Constant::SymbolKind::NULL
	$stderr.puts("Unknown symbol kind for #{entry.class}. Please report this as a bug")
	Constant::SymbolKind::NULL