Linting fails when clippy finds an error in a dependency

[WhiteBlackGoose]

Have you read the docs and searched existing issues?

• I have read the README's troubleshooting guide and FAQ(https://github.com/mrcjkb/rustaceanvim?tab=readme-ov-file#left_speech_bubble-faq).
• I am using the latest rustaceanvim release.
• 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.
• This is an issue about rustaceanvim, not rust-analyzer or Neovim.
• This is not an issue with autocompletion.

Neovim version (nvim -v)

v0.10.2

Operating system/version

NixOS unstable

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 1.81.0-nightly (6292b2a 2024-07-02)
- OK Cargo: found cargo 1.81.0-nightly (4ed7bee47 2024-06-25)
- OK rustc: found rustc 1.81.0-nightly (6292b2af6 2024-07-02)
- ERROR Failed to run healthcheck for "rustaceanvim" plugin. Exception:
  .../data/nvim/lazy/rustaceanvim/lua/rustaceanvim/health.lua:104:       cargo-nextest: not found: Could not find an executable binary.
        rustaceanvim requires [cargo-nextest](https://nexte.st).
              Next generation test runner for Rust projects.
        Optional dependency, required if the 'tools.enable_nextest' option is set.

My actual config:

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.81.0-nightly (6292b2a 2024-07-02)
- OK Cargo: found cargo 1.81.0-nightly (4ed7bee47 2024-06-25)
- OK rustc: found rustc 1.81.0-nightly (6292b2af6 2024-07-02)
- 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

Cargo.toml:

[workspace]
members = [ "mylib","t1"]

./mylib/Cargo.toml:

[package]
name = "mylib"
version = "0.1.0"
edition = "2021"

[dependencies]

./mylib/src/lib.rs:

#![deny(unused)]
pub fn add(left: u64, right: u64) -> u64 {
    let a = 3;
    left + right
}

./t1/Cargo.toml:

[package]
name = "t1"
version = "0.1.0"
edition = "2021"

[dependencies]
mylib = { path = "../mylib" }

./t1/src/main.rs:

fn main() {
    let a: i32 = "";
    println!("Hello, world!");
}

Now open ./t1/src/main.rs with nvim (or nvim -u minimal.lua). The erroneous line is not linted. Sanity check: open ./mylib/src/lib.rs, it lints the unused variable.

I believe it has to do with rustaceanvim because it works both with lspconfig's and rust-tools configurations of RA, but not with rustaceanvim.

Expected behaviour

It lints both the unused variable in the dependency AND a type mismatch in the bin project.

Actual behaviour

If there's a clippy error in a dependency, the linting stops there.

It's worth noting that it works as usual if it is not an error, but, for example, a warning:

The minimal config used to reproduce this issue.

The one suggested by this form reproduces the issue:
https://github.com/mrcjkb/rustaceanvim/blob/master/troubleshooting/minimal.lua

[mrcjkb]

Hey 👋

I believe it has to do with rustaceanvim because it works both with lspconfig's and rust-tools configurations of RA, but not with rustaceanvim.

This is because rustaceanvim enables clippy by default, if it detects that clippy is installed.
If you don't want that behaviour, you can disable clippy, see :h rustaceanvim.config.

If you want to use clippy with rust-analyzer, then I suggest opening an issue there.

[WhiteBlackGoose]

I can't find a way around it for now. Really sad, maybe I'll have to migrate back to rust-tools. Thanks for your help

[mrcjkb]

I just tried to reproduce using your setup, and made the following observation:

• If I comment out the #![deny(unused)] from mylib/src/lib.rs, linting works fine in both packages.
• If I introduce an error (it doesn't matter if it's a clippy error, e.g. change left: u64 to left: &str), it stops linting in t1/src/main.rs.

This appears to be because t1 depends on mylib and linting will fail if mylib has a compile error.

I don't know why it worked for you with rust-tools, but this is likely caused by the toolchain (you're either using a different version or have it configured differently with rustaceanvim). Rustaceanvim doesn't explicitly set any configs related to this, so it's more likely the toolchain.

[WhiteBlackGoose]

made the following observation

Yes, I reflected exactly in my screenshots.

don't know why it worked for you with rust-tool

I guess because rust-tools used clippy and I enabled RA on top via lspconfig, so they both worked and yielded different linting, which together gave me what I needed. Now rustaceanvim discourages doing that, and it does work weird so I'm not going to hack it, but maybe there's another way..

[mrcjkb]

What do you mean by " enabled RA on top via lspconfig"? RA = rust-analyzer?
rustaceanvim uses rust-analyzer, too. It just doesn't go through nvim-lspconfig. Both rustaceanvim and nvim-lspconfig use vim.lsp.start to start the client. And as I said, rustaceanvim doesn't do anything to configure diagnostic settings.

If you're absolutely sure you're using the same toolchain with both plugins, I suggest you run :lua =vim.lsp.get_clients()[1].settings and :lua =vim.lsp.get_clients()[1].capabilities and compare between the two plugins.