The LSP spec has this to say about initialize:
> Until the server has responded to the `initialize` request with an
> `InitializeResult`, the client must not send any additional requests
> or notifications to the server.
(https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize)
The spec is not really explicit about how to handle this scenario.
Before a client sends the 'initialize' request we are allowed to send an
'exit' notification, but after 'initialize' we can't send any requests
(like shutdown) or notifications (like exit). So my intepretation is
that we should forcefully close the server in this state.
This matches the behavior of Neovim's built-in LSP client:
5ceb2238d3/runtime/lua/vim/lsp.lua (L1610-L1628)
Language Servers are now configured in a separate table in `languages.toml`:
```toml
[langauge-server.mylang-lsp]
command = "mylang-lsp"
args = ["--stdio"]
config = { provideFormatter = true }
[language-server.efm-lsp-prettier]
command = "efm-langserver"
[language-server.efm-lsp-prettier.config]
documentFormatting = true
languages = { typescript = [ { formatCommand ="prettier --stdin-filepath ${INPUT}", formatStdin = true } ] }
```
The language server for a language is configured like this (`typescript-language-server` is configured by default):
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "efm-lsp-prettier", only-features = [ "format" ] }, "typescript-language-server" ]
```
or equivalent:
```toml
[[language]]
name = "typescript"
language-servers = [ { name = "typescript-language-server", except-features = [ "format" ] }, "efm-lsp-prettier" ]
```
Each requested LSP feature is priorized in the order of the `language-servers` array.
For example the first `goto-definition` supported language server (in this case `typescript-language-server`) will be taken for the relevant LSP request (command `goto_definition`).
If no `except-features` or `only-features` is given all features for the language server are enabled, as long as the language server supports these. If it doesn't the next language server which supports the feature is tried.
The list of supported features are:
- `format`
- `goto-definition`
- `goto-declaration`
- `goto-type-definition`
- `goto-reference`
- `goto-implementation`
- `signature-help`
- `hover`
- `document-highlight`
- `completion`
- `code-action`
- `workspace-command`
- `document-symbols`
- `workspace-symbols`
- `diagnostics`
- `rename-symbol`
- `inlay-hints`
Another side-effect/difference that comes with this PR, is that only one language server instance is started if different languages use the same language server.
This prevents a freeze while shutting down when using `efm-langserver`.
`efm-langserver` exits immediately after seeing a shutdown request,
without responding to the request. We block awaiting the reply to the
shutdown request which will never come, so we time out.
This change responds to any pending requests with `Err` saying that the
stream has been closed.
This change handles a language server exiting. This was a UX sore-spot:
if a language server crashed, Helix did not recognize the exit and
continued to send requests to it. All requests would timeout since they
would not receive responses. This would also hold-up Helix closing
itself down since it would try to gracefully shutdown the server which
is implemented in the LSP spec as a request.
We could attempt to automatically restart the language server on crash.
I left this for future work since that change will need to be slightly
complicated: it will need to cover the case of a language server
repeatedly crashing.
We should not depend on jsonrpc-core anymore:
* The project just announced it's no longer actively maintained[^1],
preferring their new implementation in `jsonrpsee`.
* The types are too strict: we would benefit from removing some
`#[serde(deny_unknown_fields)]` annotations to allow language
servers that disrespect the spec[^2].
* We don't use much of the project. Just the types out of core.
These are easy to embed directly into the `helix-lsp` crate.
[^1]: https://github.com/paritytech/jsonrpc/pull/674
[^2]: https://github.com/helix-editor/helix/issues/2786
A language server may push a response which doesn't belong to any
request. With this change, we discard the response rather than
crashing.
In the case of #2474, the language server sends an error message
with a null request ID which should not ever exist in the
`pending_requests` HashMap.
closes#2474
Michael Davis
Philipp Mildenberger
Blaž Hrastnik
Timothy DeHerrera
wojciechkepka
Ivan Tham
notoria
Egor Karavaev