rust-analyzer via bazel documentation

[Danielkonge]

I have a rust-analyzer setup that seems to work okay with rules_rust and bazel now, but I am not that used to using bazel/rules_rust yet, so I would like to ask if what I do makes sense or if there is a better way.

I thought this might fit better in Discussions, but decided to make it an issue, since I think the problem is common enough that there should be better documentation. I.e., this issue is really asking for more documentation on setting up rust-analyzer with rules_rust. (I have seen http://bazelbuild.github.io/rules_rust/rust_analyzer.html, but think it would be better to write more about the rust-analyzer setup directly, so it covers more than just VSCode. Also, there seems to be a few typos in the docs - see the NOTE later.)

What I have done is to put something like the following in my .bazelrc:

build:rust_analyzer --keep_going
build:rust_analyzer --@rules_rust//:error_format=json
build:rust_analyzer --@rules_rust//:rustc_output_diagnostics --output_groups=+rustc_rmeta_output,+rustc_output
build:rust_analyzer --@rules_rust//:extra_rustc_flag=-Copt-level=0

on top of using rust_register_toolchains in my WORKSPACE file. (Also there is an alias for gen_rust_project.)

NOTE: I use rustc_output_diagnostics, rustc_rmeta_output and rustc_output but the docs say output_diagnostics, rust_lib_rustc_output and rust_metadata_rustc_output.

(So if nothing else, I think this part of the docs needs an update.)

Then in neovim I have a setup like

local cwd = vim.fn.getcwd()
local bazel_dir = '/path/to/bazel/directory'
local is_in_bazel_dir = string.sub(cwd, 1, #bazel_dir) == bazel_dir

local lspconfig = require('lspconfig')
lspconfig.rust_analyzer.setup({
  -- other setup ...
  settings = is_in_bazel_dir and {
    ['rust-analyzer'] = {
      cargo = {
        buildScripts = {
          overrideCommand = {
            'bazel',
            'run',
            '//:gen_rust_project',
            '--config=rust_analyzer',
            '//...',
          }
        },
      },
      check = {
        overrideCommand = {
          'bazel',
          'build',
          '--config=rust_analyzer',
          '//...',
        }
      },
    }
  } or nil
})

which tells rust-analyzer to use

rust-analyzer.cargo.buildScripts.overridCommand = bazel run //:gen_rust_project --config=rust_analyzer //...

and

rust-analyzer.check.overridCommand = bazel build --config=rust_analyzer //...

when in my bazel directory and just the standard setup otherwise. I am not sure how to set it up per directory in other editors, but I think the VSCode setup should just be something like:

{
  "rust-analyzer.cargo.buildScripts.overrideCommand": ["bazel", "run", "--config=rust_analyzer", "//:gen_rust_project","//..."],
  "rust-analyzer.check.overrideCommand": ["bazel", "build", "--config=rust_analyzer", "//..."]
}

My question is now if this kind of setup makes sense? Am I doing something weird in the buildScripts override?

Also, is there an easy way to not have my rust-analyzer builds interfere with my usual build cache (because of the change of flags)? It would be nice to have it behave even more like cargo check although my current setup works okay.

Either way, I think slightly better documentation for setting up rust-analyzer would be good.

[cameron-martin]

I don't think that cargo.buildScripts.overrideCommand should run gen_rust_project. That is the role of rust-analyzer.workspace.discoverConfig, and support for that is being introduced in #3073.

According to the rust-analyzer docs, both cargo.buildScripts.overrideCommand and rust-analyzer.check.overrideCommand run pretty similar cargo check commands by default:

cargo check --quiet --workspace --message-format=json --all-targets --keep-going
cargo check --workspace --message-format=json --all-targets

For cargo.check.overrideCommand, there is the opportunity to use $saved_file to only build a subset of the workspace, but I'm not sure how best to utilise this.

As for which output groups we need for each command, I'm also not sure.

[Danielkonge]

Sorry for the slow reply.

I don't think that cargo.buildScripts.overrideCommand should run gen_rust_project. That is the role of rust-analyzer.workspace.discoverConfig, and support for that is being introduced in #3073.

I think you are right, this was written some time ago and I have since discovered that the build script command was useless.

As mentioned above, I think what I wrote works okay, my main issue is just that checks interfere with my usual build-cache. I have been told that this should not be too hard to fix, but I haven't really had time to look into it.

Other than that, my main comment in this issue was that I think there are (were?) typos in the docs, since the output groups I saw in the code didn't match the docs, and it would in general be nice with better docs for setting up something like a cargo check.

[cameron-martin]

Related: #1649

[cameron-martin]

I thought that the "cargo check"-like functionality described here worked before, but it seems like it doesn't anymore. I just get errors like this:

2025-05-09T17:32:41.62088618+01:00 ERROR flycheck 0: File with cargo diagnostic not found in VFS: file not found: /home/cameron/Repos/camos/bazel-out/k8-fastbuild-ST-e5304c15b1af/bin/crates/camos_uefi/src/main.rs

This makes sense, because without first resolving symlinks these are not files within the editor's workspace. Maybe rust-analyzer has stopped resolving symlinks here?