Wont attach to dependencies

[GordianDziwis]

Checked other resources

• This is not a bug report or feature request (Please use issues for those).
• This is a question about rustaceanvim, not rust-analyzer or Neovim.
• This is not a question about autocompletion.
• I have read the README.
• I have read the FAQ.
• I have searched for a solution using :h rustaceanvim.
• I have searched existing discussions.
• I have searched the existing issues/discussions of other plugins related to this question (if applicable).
• I have searched the existing rust-analyzer discussions (if applicable).
• I have added a very descriptive title to this question.

Description

With 7c66c1b rust-analyser won't attach to source files from dependencies anymore. Is this intended?

Example Code

Neovim version (nvim -v)

v0.12.0

Operating system/version

Ubuntu

Output of :checkhealth rustaceanvim

==============================================================================
rustaceanvim:                           require("rustaceanvim.health").check()

Checking for Lua dependencies ~
- ✅ OK [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap) installed.

Checking external dependencies ~
- ✅ OK rust-analyzer: found rust-analyzer 1.86.0 (05f9846 2025-03-31)
- ✅ OK Cargo: found cargo 1.86.0 (adf9b6ad1 2025-02-28)
- ✅ OK rustc: found rustc 1.86.0 (05f9846f8 2025-03-31)
- ✅ OK cargo-nextest: found cargo-nextest 0.9.93 (c4863f26c 2025-03-24)
- ✅ OK debug adapter: found codelldb 

Checking config ~
- ✅ OK No errors found in config.

Checking for conflicting plugins ~
- ✅ OK No conflicting plugins detected.

Checking for tree-sitter parser ~
- ✅ OK tree-sitter parser for Rust detected.

[mrcjkb]

Hey 👋

thanks for reporting.
No, that is not the intended behaviour,

#724

[papricasix]

@mrcjkb Thank you for your great work!

Unfortunately with #725 I'm still having an issue. If I load a session with two buffers open (side by side), only one get's the LSP attached.

[mrcjkb]

Hmm, I can't reproduce that (neither with 2 different files nor 2 buffers with the same file open in a vertical split).
Could you please follow the troubleshooting guide to reproduce with a minimal config and file a bug report if you can?

[YaLTeR]

I hit this problem and found a weird workaround. Here are some details. Maybe this will help nail down the problems.

First of all, rustaceanvim picks up vim.lsp.config settings from vim.lsp.config('rust-analyzer', {}), with the dash. However, nvim-lspconfig without rustaceanvim picks up settings from vim.lsp.config('rust_analyzer', {}), with the underscore. Neither sees the other one's spelling. I'm not sure if this is intentional. I'd expect these to be unified, so the same vim.lsp.config works both with and without rustaceanvim.

Then, configuring RA with rustaceanvim through vim.lsp.config('rust-analyzer', {}) prevents it from working when going-to-definition into dependency source code (it fails to attach to the buffer for some reason). Configuring through vim.g.rustaceanvim = { server = { default_settings = {} } } however works fine. Using nvim-lspconfig without rustaceanvim (and configuring it through vim.lsp.config('rust_analyzer', {})) also works fine.

[mrcjkb]

I'm not sure if this is intentional. I'd expect these to be unified, so the same vim.lsp.config works both with and without rustaceanvim

Yes, this is intentional. Why would they be unified? rustaceanvim and nvim-lspconfig are two different plugins. nvim-lspconfig's rust_analyzer client conflicts with rustaceanvim and rustaceanvim supports configuration options that nvim-lspconfig doesn't.

configuring RA with rustaceanvim through vim.lsp.config('rust-analyzer', {}) prevents it from working when going-to-definition into dependency source code

I cannot reproduce this when switching my personal config to use vim.lsp.config instead of vim.g.rustaceanvim.
This is likely either a configuration issue on your end or another plugin interfering, which is why I recommend to follow the troubleshooting guide to reproduce issues with a minimal config and then bisect your config/plugins.

[YaLTeR]

Yes, this is intentional. Why would they be unified? rustaceanvim and nvim-lspconfig are two different plugins. Nvim-lspconfig's rust_analyzer client conflicts with rustaceanvim and rustaceanvim supports configuration options that nvim-lspconfig doesn't.

I see. Well, it's certainly very confusing and surprising. Should call it something like rustaceanvim-rust-analyzer maybe?

I cannot reproduce this when switching my personal config to use vim.lsp.config instead of vim.g.rustaceanvim.
This is likely either a configuration issue on your end or another plugin interfering, which is why I recommend to follow the troubleshooting guide to reproduce issues with a minimal config and then bisect your config/plugins.

Hm, unfortunate. Well, it's working for me with vim.g.rustaceanvim so the immediate problem is solved..

[mrcjkb]

Well, it's certainly very confusing and surprising.

If someone is confused/surprised because they didn't read the docs, that's on them 😅

Should call it something like rustaceanvim-rust-analyzer maybe?

That would be unnecessarily verbose, plus it would be a breaking change.
The name of rustaceanvim's LSP client (and the name of the language server) is rust-analyzer. That was the case before vim.lsp.config was a thing. 'rust-analyzer' makes the most sense.

[YaLTeR]

I don't disagree, just it's surprising that - vs. _ is the only difference

[mrcjkb]

I believe nvim-lspconfig chose an underscore in their client name because the module in which they configure rust-analyzer is called rust_analyzer due to Lua module naming restrictions.
In any case, my design decisions are in no way influenced by the existence of another plugin that also configures a rust-analyzer client. I don't even use nvim-lspconfig.

It's actually mostly beneficial that the clients have different names, because when someone has an issue that's caused by using both nvim-lspconfig and rustaceanvim to set up conflicting rust-analyzer clients, you can tell quite quickly from the client names.