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?

[refi64]

Was using Bazel for a rust project and ended up going down a rabbit hole to try and work around the cache issues.

First off, the environment used to run bazel from rust-analyzer will probably be sufficiently different to thrash the cache even before we get to anything else, so you need:

build --incompatible_strict_action_env

in your .bazelrc. Next up, there are two issues with doing a normal bazel build and passing command-line flags to change the output:

• The CLI flags themselves will toss the analysis cache.
• Once the project builds successfully, bazel of course won't run rustc again...which means that warnings disappear after the first save.

In order to work around this, I created a wrapper rule that uses transitions to build the dependencies and generates a wrapper script that cats the rustc output:

load("@aspect_bazel_lib//lib:paths.bzl", "BASH_RLOCATION_FUNCTION", "to_rlocation_path")
load("@rules_rust//rust:rust_common.bzl", "CrateInfo")

def _transition_output_impl(settings, attr):
    return {
        "@rules_rust//:error_format": "json",
        "@rules_rust//:rustc_output_diagnostics": True,
    }

_transition_output = transition(
    implementation = _transition_output_impl,
    inputs = [],
    outputs = [
        "@rules_rust//:error_format",
        "@rules_rust//:rustc_output_diagnostics",
    ],
)

def _rust_analyzer_check_impl(ctx):
    replay_script = ctx.actions.declare_file("%s_replay.sh" % ctx.label.name)

    rustc_outputs = []
    for dep in ctx.attr.deps:
        info = dep[OutputGroupInfo]
        if "rustc_rmeta_output" in info:
            rustc_outputs.extend(info.rustc_rmeta_output.to_list())
        elif "rustc_output" in info:
            # TODO: somehow generate rmeta for binaries too?
            rustc_outputs.extend(info.rustc_output.to_list())
        else:
            fail("%s has no rustc outputs" % dep)

    ctx.actions.write(
        output = replay_script,
        content = BASH_RLOCATION_FUNCTION + "\ncat " + " ".join([
            "$(rlocation %s)" % to_rlocation_path(ctx, output)
            for output in rustc_outputs
        ]),
        is_executable = True,
    )
    return [
        DefaultInfo(
            executable = replay_script,
            files = depset(rustc_outputs),
            runfiles = ctx.runfiles(rustc_outputs).merge(ctx.attr._runfiles.default_runfiles),
        ),
    ]

rust_analyzer_check = rule(
    _rust_analyzer_check_impl,
    attrs = {
        "_allowlist_function_transition": attr.label(
            default = "@bazel_tools//tools/allowlists/function_transition_allowlist",
        ),
        "_runfiles": attr.label(default = "@bazel_tools//tools/bash/runfiles"),
        "deps": attr.label_list(
            allow_empty = False,
            cfg = _transition_output,
            providers = [OutputGroupInfo, CrateInfo],
        ),
    },
    executable = True,
)

And then you can do

rust_analyzer_check(
  name = "check",
  deps = [":my_rust_binary"],
)

and now bazel run //:check will print out all the JSON diagnostics, without touching the cache, and including warnings.

(Note the way it takes multiple dependencies is kinda broken, because if one fails then you'll stop getting warnings for the other ones; their output never gets replayed! I didn't get around to fixing that though, because I ditched this for reasons outlined below...)

The thing is, this has a big inherent issue:

        if "rustc_rmeta_output" in info:
            rustc_outputs.extend(info.rustc_rmeta_output.to_list())
        elif "rustc_output" in info:
            # TODO: somehow generate rmeta for binaries too?
            rustc_outputs.extend(info.rustc_output.to_list())

rust_binary rules always build the entire thing, rather than just building the .rmeta file like cargo does, so the runtime of this is pretty slow compared to cargo check. Working around that would almost certainly require rules_rust changes.

Around this point though, I realized that rust_clippy already kinda does what I want: it doesn't build the output all the way. But its aspect behaves a bit differently in that output is always written to the file, even on error, so the "save the output and replay" trick no longer works. Thus I ended up with:

load("@rules_rust//rust:defs.bzl", "rust_clippy_aspect")
load("@rules_rust//rust:rust_common.bzl", "ClippyInfo", "CrateInfo")

def _transition_output_impl(settings, attr):
    return {
        "@rules_rust//:capture_clippy_output": True,
        "@rules_rust//:error_format": "json",
    }

_transition_output = transition(
    implementation = _transition_output_impl,
    inputs = [],
    outputs = [
        "@rules_rust//:capture_clippy_output",
        "@rules_rust//:error_format",
    ],
)

def _rust_clippy_json_impl(ctx):
    return [
        DefaultInfo(
            files = depset(ctx.attr.dep[0][ClippyInfo].output.to_list()),
        ),
    ]

rust_clippy_json = rule(
    _rust_clippy_json_impl,
    attrs = {
        "_allowlist_function_transition": attr.label(
            default = "@bazel_tools//tools/allowlists/function_transition_allowlist",
        ),
        "dep": attr.label(
            cfg = _transition_output,
            providers = [CrateInfo],
            aspects = [rust_clippy_aspect],
        ),
    },
)

Now I can put this in my BUILD:

rust_clippy_json(
    name = "clippy_json",
    dep = ":my_rust_project",
)

and then get editor diagnostics by cat-ting the output files manually via a shell wrapper:

bazel --quiet build //:clippy_json 2>/dev/null || :
cat $(bazel --quiet cquery //:clippy_json --output=files)

The result works pretty quickly (the entire thing runs in ~2s) and also gives me the more verbose clippy diagnostics, which I should probably be using anyway. Unfortunately, the final cquery adds another half-second to the time, but ehh this is good enough for me.

[AlexOrozco1256]

Hey @refi64, I'm following your setup (thanks btw!) and the json produced is mostly the same as the json produced by the default cargo check command that rust-analyzer uses. It's missing information about the target crate/path. I'm wondering if you did any work on top of this to get your IDE to use the json output to do syntax/error highlighting?

I'm mostly interested in the error (squiggly line) highlighting. The error json output is isolated already in bazel-out/_tmp/actions/stderr-2. I'm trying to solve this now by writing a script that runs clippy_json and adds the minimum necessary file path information to the json for the error highlighting.