Crash On Unrecognized CompletionItemKind

[lordmilko]

I am attempting to build a language client against haskell-language-server in Visual Studio 2019.

When I follow the instructions for doing so however, haskell-language-server-wrapper fails with the following error

2022-09-24T11:34:34.192704Z | Info | Starting server
2022-09-24T11:34:34.193704Z | Error | Got error while decoding initialize:
Error in $.params.capabilities.textDocument.completion.completionItemKind.valueSet[0]: CompletionItemKind

Upon further investigation, it seems the issue is that in the CompletionItemKind enumeration defined in Microsoft.VisualStudio.LanguageServer.Protocol.dll, the first element of this enumeration is None. Visual Studio attempts to pass all members of this enumeration as supported completion kinds to the language server. In the A.FromJSON declaration, None is not a valid identifier, resulting in fail "CompletionItemKind" being called, which I believe is what leads to the exception above.

According to the LSP Specifiaction:

To support the evolution of enumerations the using side of an enumeration shouldn’t fail on an enumeration value it doesn’t know. It should simply ignore it as a value it can use and try to do its best to preserve the value on round trips. Lets look at the CompletionItemKind enumeration as an example again: if in a future version of the specification an additional completion item kind with the value n gets added and announced by a client a (older) server not knowing about the value should not fail but simply ignore the value as a usable item kind.

There are actually 13 "additional" values in the CompletionItemKind enum of Microsoft.VisualStudio.LanguageServer.Protocol.dll, so I believe the key issue here is that haskell/lsp (and by extension haskell-language-server) do not correctly ignore unknown enumeration values as recommended by the LSP specification. This may potentially affect other LSP enumeration kinds implemented by this project as well

Attached is the log output of haskell-language-server-wrapper that generated this error

log.log

[michaelpj]

Hmmm, we do assume that enumerations have fixed sets of values unless the spec says that they're extensible. The new, machine-readable version of the spec even has a special property for enumerations that allow custom values - and CompletionItemKind does not have it. But I agree that the spec seems ambiguous here. I'll ask upstream.

[michaelpj]

microsoft/vscode-languageserver-node#1088

[michaelpj]

Thanks, it seems like this is indeed a bug, and all enumerations are expected to be open. I'll fix this in my metamodel-generation branch, but I probably won't fix this in current versions of lsp.

[lordmilko]

Thanks @michaelpj,

When you say it won't be fixed in current versions of lsp are you able to clarify what you mean by that? I would imagine that all previous releases of lsp would of course contain this bug (since they have already been released), but once the change is merged into master I would imagine this fix would be in the next release after that

[michaelpj]

Sorry, I meant the "current design" I guess. I have a very large PR that redoes almost the whole package, I'm not planning to modify the existing code until that hits. That said, if this is a real blocker for you I'd accept a PR and do a minor release.

[michaelpj]

Argh, I did not in fact fix this! I forgot about this insanity where literally all enums are open. Still need to do it.