LazyVim: No useful diagnogstics ever show

[mlp1802]

Have you read the docs and searched existing issues?

• I have read the README's troubleshooting guide.
• I have searched existing issues.
• I have searched existing discussions.
• I have searched the existing issues of other plugins related to this issue (if applicable).
• I have searched the existing rust-analyzer issues (if applicable).
• I can reproduce the issue with stable Neovim (not a distribution or nightly) and the minimal config.

Neovim version (nvim -v)

10

Operating system/version

Ubuntu

Output of :checkhealth rustaceanvim

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

Checking for Lua dependencies ~
- WARNING dap not installed. Needed for debugging features [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap)

Checking external dependencies ~
- OK rust-analyzer: found rust-analyzer 0.3.1782-standalone
- OK Cargo: found cargo 1.79.0-nightly (d438c80c4 2024-03-19)
- OK rustc: found rustc 1.79.0-nightly (0ad927c0c 2024-03-21)
- 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.

How to reproduce the issue

Open my neovim :)

Expected behaviour

Diagnogstics should show

Actual behaviour

After upgrading lazyvim no helpful diagnogstics other than missing semicolon etc is shown.
I'm not sure, but I think lazyvim just recently began to use this plugin, as after some digging I found that it completely ignored my custom rust_analyzer lsp setup.
I know have a complete replica up this setup, as described on lazyvims website.
https://www.lazyvim.org/extras/lang/rust
Everything works, except diagnogstics. I simply get the message "no diagnogstics found".

The minimal config used to reproduce this issue.

local common = require("config.common")
return {
  "mrcjkb/rustaceanvim",
  enabled = true,
  version = "^4", -- Recommended
  ft = { "rust" },
  opts = {
    server = {
      on_attach = function(_, bufnr)
        vim.keymap.set("n", "<M-3>", common.workspace_diagnostics, { noremap = true, silent = true })
        vim.keymap.set("n", "<M-w>", common.document_diagnostics, { noremap = true, silent = true })
        vim.keymap.set("n", "<M-w>", common.document_diagnostics, { noremap = true, silent = true })
        vim.keymap.set("n", "<leader>cR", function()
          vim.cmd.RustLsp("codeAction")
        end, { desc = "Code Action", buffer = bufnr })
        vim.keymap.set("n", "<leader>dr", function()
          vim.cmd.RustLsp("debuggables")
        end, { desc = "Rust debuggables", buffer = bufnr })
      end,
      default_settings = {
        -- rust-analyzer language server configuration
        ["rust-analyzer"] = {
          cargo = {
            allFeatures = true,
            loadOutDirsFromCheck = true,
            runBuildScripts = true,
          },
          -- Add clippy lints for Rust.
          checkOnSave = {
            allFeatures = true,
            command = "check",
            extraArgs = { "--no-deps" },
          },
          procMacro = {
            enable = true,
            ignored = {
              ["async-trait"] = { "async_trait" },
              ["napi-derive"] = { "napi" },
              ["async-recursion"] = { "async_recursion" },
            },
          },
        },
      },
    },
  },
  config = function(_, opts)
    vim.g.rustaceanvim = vim.tbl_deep_extend("keep", vim.g.rustaceanvim or {}, opts or {})
  end,
}

[mrcjkb]

Hey 👋

Please don't check the checkboxes without reading them.

Converting to a Q&A discussion, as this is a LazyVim issue, not a rustaceanvim bug.

I don't have the capacity to support all the Neovim distributions out there, so I can only suggest the following:

• Follow the troubleshooting guide starting from a minimal config and plain neovim, as recommended in the bug report form.
• Open a Q&A discussion in the LazyVim repo. People who use LazyVim will be more likely to be able to help you than I am 😀

Edit: Your checkOnSave.command looks very fishy by the way:

1. It's the wrong command for clippy
2. You shouldn't need to set anything for checkOnSave, as rustaceanvim will automatically detect if you have clippy installed and then set it for you.

[ArcusCerebellumus]

Do you have your project setup as a lib with a bin folder for compiling multiple executables?

Because I do, and I have the same issue, whereas the default style project with main.rs has no problem with diagnostics. And even in my non-orthodox (read it as "jank" if you prefer) setup when I edit anything that's within the scope of my crate (i.e. included somewhere via mod/use) - the diagnostics work just fine.

PS: ...and just like in your case, before I moved to use this plugin (instead of manually setting everything up) and LSP provided from Rustup (instead of one that Mason ships) all of those issues didn't exist for me. :|

[mrcjkb]

@ArcusCerebellumus

before I moved to use this plugin (instead of manually setting everything up) and LSP provided from Rustup (instead of one that Mason ships) all of those issues didn't exist for me.

I don't understand this sentence. Did you use rustup before, and are using mason with this plugin now? Or the other way around?

[ArcusCerebellumus]

I used Mason for getting rust_analizer before, just today I moved away from it and got what seems to be the exact same issue as the OP, among others.

What's worse is that restructuring is not really an option at this point :|

[mrcjkb]

It's still possible to use mason.nvim's installation with this plugin. You just need to set the server.cmd manually (getting the path to the binary from mason-registry) and make sure mason-lspconfig (if you're using it) doesn't set up a conflicting nvim-lspconfig client.

See :h rustaceanvim.mason

You can also try running cargo clean in your project. One reason it might have been working with mason in your case, is that when rust-analyzer has been built with a different toolchain than your project, it needs to recompile everything.

[ArcusCerebellumus]

Checked your recompilation theory - didn't help.

But you gave me an idea. From the results of what I did, it became evermore obvious that the compiler KNOWS where everything is - it's the LSP who's clueless. I thought, "Maybe I should help it a little," and since its main function is semantic analysis - I decided to be AS CLEAR as possible.

Fixed up my bin files by adding explicit extern declarations (as opposed to the implicit ones as they were before):

+ extern crate blah;

Also had to massage my imports a bit,

- use old_name::{
+ use blah::{

Also-also I had a naming "conflict" between my package and one of the binaries - fixed that too.

Somewhat of a needless exercise, but now LSP is happy! Throwing error messages like it's no tomorrow :D

[op8867555]

Hi,
I ran into a similar problem (#324), I've tried the minimal config setup or downgrading lazy.nvim but still not working :/
Any suggestions to diagnostic this?

[op8867555]

Thanks for the explanation, I checked the both capabilities reported by RA but not much difference there.

It turns out the problem is caused by clippy in my case, rust-tools.nvim didn't support clippy and my codebase has some clippy errors. After I turn off enable_clippy, cargo-check diagnostics shows up again. It seems there won't be any cargo-check diagnostics when clippy generating errors.

[mrcjkb]

Thanks for the insight. That's good to know.

[Sotatek-TruongNguyen2]

I have a similar problem @op8867555 . May i know how to turn off enable_clippy ?

[mrcjkb]

See :h rustaceanvim.config and :h rustaceanvim.tools.Opts.

[Sotatek-TruongNguyen2]

It's working for me now. Thanks u @mrcjkb Really appreciate that

[bryanmaina]

This just happened to me I would like to add to procedure that checks if everything is ok before playing with any rustaceanvim option:
"You should make sure that the project builds in the same terminal you are running vim/neovim in. And if you are running sessions(tmux for example) try to build in that same session you are running the editor in. If you have an issue building in that session clippy will not work."

In my case, for some reason, I run : export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig to solve some build problems with openssl-sys on WSL and then reopened a tmux session where I run neovim. l but that export was not picked up by the tmux session.

It took me 3 hours to find the PKG_CONFIG_PATH was not set in any tmux session I reopened and that is why clippy was failing and no diagnostic were shown but it was working fine outside of those sessions.