How to setup rust-analyzer to use cross-rs?

Editors and IDEs
1

Hi.
I am trying to setup cross-rs to use together with rust-analyzer.
The project has to be built for amv7 and I have also some precompiled dependencies.
Therefore I set everything up with a custom cross-rs Dockerimage and use cross to build and test.
This works fine.

I also updated the check command for rust-analyzer, which worked for my basic project, but it started failing when I added mockall with the following error.

proc macro `automock` not expanded: No proc-macros present for crate

Also rust-analyzer was looking for the target directory in my os-root, which I could fix with a symlink.

When I call cross build with my target it throws no errors.

I suspect that rust-analyzer has something that is run outside of docker container of cross-rs.

My current rust-analyzer configuration.

    "rust-analyzer": {
        "check":{
            "features":"all",
            "overrideCommand": ["cross", "check", "--message-format=json","--target=armv7-unknown-linux-gnueabihf"],
            "targets": "armv7-unknown-linux-gnueabihf"
        },
        "cargo":{
            "buildScripts": {
                "overrideCommand": ["cross", "check", "--message-format=json","--target=armv7-unknown-linux-gnueabihf"]
            },
            "target": "armv7-unknown-linux-gnueabihf"
        }
    }
}

Rust analyzer version rust-analyzer 1.76.0 (07dca48 2024-02-04)
Host Arch is x86_64 with Linux

Is there a guide to setup Rust-analyzer with cross-rs to have all the building happen with cross, because of dependencies that are precompiled for the target platform ?
Or can somebody give me some support to get it working?

2

I don't have a cross-rs setup for now, just some guesses based on your description, so you need to test it out yourself.

rust-analyzer needs to run a separate process on the host to evaluate and expand procedural macros, and by default a program named rust-analyzer-proc-macro-srv is used, which is part of the rustc component. I didn't test whether it will work if the toolchain is containerized, but there's a setting named rust-analyzer.procMacro.server, you can try to point it to a docker run command (or a wrapper script)

also, rust-analyzer want to scan the source code for the standard libraries (i.e. core, std) from the "sysroot", which is controlled by the setting rust-analyzer.cargo.sysroot (or directly rust-analyzer.cargo.sysrootSrc to be precise). I believe you can run cross rustc --print sysroot to get this information, but you need to figure out a way to export or bind the path of the container to the host somehow.

3

forget to mention, this program is part of rustc (instead of rust-analyzer), but it is installed under the directory libexec, not bin

4

Thank you for the quick reply.

I recreated the docker environment like cross-rs is using it and called the rust-analyzer-proc-macro-srv
Because of the following error

[ERROR][2024-03-19 22:02:43] .../vim/lsp/rpc.lua:734	"rpc"	"rust-analyzer"	"stderr"	"If you're rust-analyzer, you can use this tool by exporting RUST_ANALYZER_INTERNALS_DO_NOT_USE='this is unstable'.\nIf not, you probably shouldn't use this tool. But do what you want: I'm an error message, not a cop.\n"

it now looks as like this

RUST_ANALYZER_INTERNALS_DO_NOT_USE='this is unstable' rust-analyzer-proc-macro-srv

The procMacros still are not expanded. I do not get any error messages, apart from the proc macro errors and the logs are empty.

Is there something else I need to add to call it correctly ?

I also tried to use the same technique and start the rust-analyzer in the container. It works for now, but it is very slow when I am in a file with proc macros.
In this case it is a file that includes C bindings generated by bindgen. They are annotated with #[automock] and I have a few tests.

When I try to use a code action to auto import some function, it takes 5 - 10 secs to open the menu to select the code action. And rust-analyzer uses almost 10x the memory, compared to the one outside of docker without proc macros.

Do you have an idea where the performance hit could come from?

5

I think running the lsp server in the container is the way to go. as for the performance issue, I've no idea why, and I never used the automock thing. maybe it's just the macro expands into over complicated code for rust-analyzer to parse. what's the performance if you are not cross compiling but natively?

6

Yes, apart from the issue with automock it works quite well.

I did some tests and without the automock everything works as expected, but with it, the auto completions is slow and the onSave check takes forever.

Is there a possibility to cache the expanded procMacros ?
And can I see somewhere what code is generated by automock ?

7

I think macros should be evaluated lazily. I think expanding the macro probably is not the cause of the slow down, rather it's the expanded code is too complex to parse.

I think rust-analyzer itself has this feature implemented, as the vscode plugin has a command to expand macros recursively, but I don't know whether it's possible using LSP only (it probably uses some private extension to the core LSP protocol).

but if you have the nightly toolchain installed, you can ask the compiler to do the work, just use this command:

$ cargo rustc --profile=check -- -Zunpretty=expanded

also check out cargo-expand (a wrapper for the above command, still requires nightly):

8

Thanks you for your help.

I will have to investigate the performance Issue, but the basic problem is solved I think.

The solution was to call the following.

cross-util run -i --target <target> -- rust-analyzer

This start rust-analyzer inside a container, provided by cross.

1 Like
9

I just checked how much code is added by the expansion of #[automock] in my code.
And it adds 70k lines for my 600. This definitely explains the lag.

Thanks again for your help.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.