Incorrect capabilities injected into lsp config

[jeremimucha]

Make sure you have done the following

• Updated to the latest version of blink.cmp
• Searched for existing issues and documentation (try <C-k> on https://cmp.saghen.dev)

Bug Description

Versions 1.9.1 and 1.9.0 cause incorrect, at a glance rust-analyzer-related, capabilities to be injected into the lsp configuration. This occurs for all LSPs that I've tried - clangd, lua_ls, pyright, basedpyright.
The issue does not occur on 1.8.0.

Issue occurs on nvim 0.11.0 - the latest version installed in my work environment, sadly I'm currently unable to update.
NAME="Red Hat Enterprise Linux"
VERSION="8.10 (Ootpa)"
ID="rhel"
VERSION_ID="8.10"
ARCH: x86_64

I was unable to reproduce this on my other machine running latest nightly nvim build.
The issue could possibly be related to issue #2379.

Reproduction

Reproduce using the following minimally-edited repro.lua (version pinned + "InsertEnter" load event).
Steps:

1. nvim -u repro.lua
2. :e repro.lua
3. :LspInfo -- lua_ls configuration is the default from lspconfig, capabilities clean
4. i<Escape> -- enter and quit insert mode - loads blink.cmp
5. :LspInfo -- lua_ls capabilities extended, include some capabilities incorrect for this lsp, causing it to misbehave, in case of other LSPs causes crashes (e.g. for pyright)

repro.lua:

-- Run with `nvim -u repro.lua`

vim.env.LAZY_STDPATH = '.repro'
load(vim.fn.system('curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua'))()

---@diagnostic disable-next-line: missing-fields
require('lazy.minit').repro({
  spec = {
    {
      'saghen/blink.cmp',
      version = "1.9.0",  -- also happens on 1.9.1, does not reproduce on 1.8.0
      event = "InsertEnter",
      opts = {},
    },
    {
      'mason-org/mason.nvim',
      build = ':MasonUpdate',
      opts = {},
    },
    {
      'mason-org/mason-lspconfig.nvim',
      dependencies = { 'mason-org/mason.nvim', 'neovim/nvim-lspconfig' },
      opts = {
        ensure_installed = { 'lua_ls' },
      },
    },
  },
})

Configuration before loading blink.cmp:

vim.lsp: Enabled Configurations ~
- lua_ls:
  - cmd: { "lua-language-server" }
  - filetypes: lua
  - root_markers: .emmyrc.json, .luarc.json, .luarc.jsonc, .luacheckrc, .stylua.toml, stylua.toml, selene.toml, selene.yml, .git
  - settings: {
      Lua = {
        codeLens = {
          enable = true
        },
        hint = {
          enable = true,
          semicolon = "Disable"
        }
      }
    }

After loading blink.cmp:

vim.lsp: Enabled Configurations ~
- lua_ls:
  - capabilities: {
      experimental = {
        commands = {
          commands = { "rust-analyzer.showReferences", "rust-analyzer.runSingle", "rust-analyzer.debugSingle" }
        },
        serverStatusNotification = true
      },
      offsetEncoding = { "utf-8", "utf-16" },
      textDocument = {
        completion = {
          completionItem = {
            commitCharactersSupport = false,
            deprecatedSupport = true,
            documentationFormat = { "markdown", "plaintext" },
            insertReplaceSupport = true,
            insertTextModeSupport = {
              valueSet = { 1 }
            },
            labelDetailsSupport = true,
            preselectSupport = false,
            resolveSupport = {
              properties = { "documentation", "detail", "additionalTextEdits", "command", "data" }
            },
            snippetSupport = true,
            tagSupport = {
              valueSet = { 1 }
            }
          },
          completionList = {
            itemDefaults = { "commitCharacters", "editRange", "insertTextFormat", "insertTextMode", "data" }
          },
          contextSupport = true,
          editsNearCursor = true,
          insertTextMode = 1
        },
        diagnostic = {
          dynamicRegistration = true,
          relatedDocumentSupport = true
        },
        semanticTokens = vim.NIL
      },
      workspace = {
        configuration = false,
        didChangeWatchedFiles = {
          dynamicRegistration = true
        },
        didChangeWorkspaceFolders = {
          dynamicRegistration = true
        },
        semanticTokens = vim.NIL,
        workspaceFolders = false
      }
    }
  - cmd: { "lua-language-server" }
  - filetypes: lua
  - root_markers: .emmyrc.json, .luarc.json, .luarc.jsonc, .luacheckrc, .stylua.toml, stylua.toml, selene.toml, selene.yml, .git
  - settings: {
      Lua = {
        codeLens = {
          enable = true
        },
        hint = {
          enable = true,
          semicolon = "Disable"
        }
      }
    }

Relevant configuration

neovim version

NVIM v0.11.0 Build type: Release LuaJIT 2.1.1741730670

blink.cmp version

1.9.1, 1.9.0

[soifou]

causing it to misbehave, in case of other LSPs causes crashes (e.g. for pyright)

How does it misbehave? I don't see pyright crashes on 0.11 + blink.cmp 1.9.0 w/ merged RA fields.

What changed since blink.cmp 1.9.x is it now respects these merged capabilities (fix #2288) instead of overwriting them. What you see in :LspInfo is expected nvim 0.11 behavior, client capabilities get merged into ['*']. Other LSPs just ignore the rust-analyzer experimental fields (per LSP spec), so it should have no functional impact on clangd, pyright, etc.

And as you notice, nvim nightly scopes them differently, there is no RA "pollution". I don't think this is a blink.cmp issue honestly.

[jeremimucha]

Thank you for taking the time to look into this.

I probably should have included more details about the crashes right away. I'll include some log snippets on Monday, I'm unable to access that machine until then.

From what I recall:
pyright and basedpyright would definitely crash for me. Message in LspLog would be something like:
server_request: no handler found for "workspace/diagnostic/refresh".
I'll need to retry with the minimal conf.

lua_ls would not crash but the lsp features would not work, goto definition, get references would just return a "not supported" notification. This would happen in the same workspace for which 1.8.0 works just fine.

Again, I'll be able to provide logs / screenshots on Monday.

Also, I only reported on the off chance that this might be an actual issue. I only thought so because rust-specific capabilities seemed suspicious in C++, lua and python workspaces. Since this does not cause issues on newer neovim versions, the root cause might indeed lie elsewhere, or be a non-issue entirely. If you decide that's the case that's totally fine by me, feel free to close. I understand time is limited and you have to triage. I myself can easily survive on 1.8.0 for another two months or so when I should be able to upgrade neovim.