Lag at neovim shutdown - LSP+rust-analyzer suspected

Neovim
1

neovim 0.5.1 is working fine on my Arch machine, but when I close it with :q it lags for almost a second if the opened buffer was a rust .rs file. I can see it doesn’t do it if the buffer was eg a .vim file. I’m using rust-analyzer and iamcco’s vim-language-server with builtin LSP.

I’ve been searching for a way to benchmark neovim’s (or vim’s) shutdown process, couldn’t find a simple way to do it. Would someone suggest something ?

2

Known issue: Delay when closing nvim with rust_analyzer active, first call to stop() ignored but fixes delay · Issue #12478 · neovim/neovim · GitHub

TBH there’s not much we can do about it. We send the shutdown command to rust-analyzer, wait for it to shut down, and it doesn’t before we sigkill it. You can file an upstream issue with rust-analyzer about the closing time.

3

Oh OK. Yes I suspected that at last. I’ll do that then.

4

I made the behavior of neovim configurable: see lsp: language server (rust-analyzer) delays quitting neovim · Issue #12478 · neovim/neovim · GitHub

Copied below:

I still consider this a “rust-analyzer closes slow problem”, but I’ve added a mitigation in core. You can pass the exit_timeout flag now in start_client. If you are using lspconifg, you can completely defer us waiting for the sever to close (and sending kill -15) as follows;

require('lspconfig').rust_analyzer.setup({ 
  ... -- your on_attach/whatever
  flags = {
    exit_timeout = false,
  }

Or send kill -15 immediately:

require('lspconfig').rust_analyzer.setup({ 
  ... -- your on_attach/whatever
  flags = {
    exit_timeout = 0,
  }

If the server remains in the former case, please do not file an issue, as this is intentionally bypassing our kill mechanism. I still recommend the default 500ms if you want the servers to both:

ensure they are killed, and do not remain as orphaned processes
ensure that your work is not lost due to killing the server in the middle of a filesystem operation