Allow rust path configuration

[yaymalaga]

In Rust (rls) vscode extension, it is possible to specify the rustup path by adding the "rust-client.rustupPath" key in the settings.json.

Would it be possible to have the same option in rust-analyzer? This would enable the extension to directly know about the location of cargo, rustc, etc

[bjorn3]

rust-analyzer never invokes rustup itself.

https://github.com/rust-analyzer/rust-analyzer/search?q=rustup&unscoped_q=rustup

[yaymalaga]

I was thinking about Cargo binary, as it is in the same folder as rustup if intalled using that tool. I have changed the title, thanks!

[kiljacken]

If I'm allowed to be a little snarky, we already have this, it's called the PATH enviroment variable :)

I'm not sure if I personally see too much value adding another way to configure it (not really any harm either, apart from added complexity of threading the configuration through to where it's needed) , I'd love if you shared your use case, as it makes it easier to evaluate :)

[matklad]

I think we should honor RUSTC and CARGO env variables (and we already honor the later, via cargo metadata), but an explicit config does seem like an overkill to me.

[matklad]

This is the place where we need to take RUSTC into account: https://github.com/rust-analyzer/rust-analyzer/blob/58f4dcf79ecf3b8dcec83d46a27a29340900a0ef/crates/ra_project_model/src/lib.rs#L430

[yaymalaga]

In my case, this issue would be related to how vscode works in Solus (Linux distro), as explained in microsoft/vscode-python#1338 (comment).

In short, the path that vscode is using internally (not happening in its embedded terminal) does not take into account the user-configured one, so that's why I had to manually add rustup path in Rust-rls extension to make it work. Therefore, with this extension I'm getting an error when it executes cargo metadata, as it is not found.

[lnicola]

@yaymalaga see #2496 (comment).

We had something about this in the install notes, but it was dropped in #3140.

[SomeoneToIgnore]

One more rustc place that needs to be taken care of in this issue: https://github.com/rust-analyzer/rust-analyzer/blob/585eef1d8c79e24b7788363cf3a5bc7c9c3bc963/crates/ra_project_model/src/sysroot.rs#L112

Also now we call rustup once here, to install rust-src when we don't find it: https://github.com/rust-analyzer/rust-analyzer/blob/585eef1d8c79e24b7788363cf3a5bc7c9c3bc963/crates/ra_project_model/src/sysroot.rs#L118
There's no environment variable for rustup, so we need to come up with something else if we plan to change this place either.
Yet it seems that for cases when it's impossible to add rustup to the path, it's better to install rust-src manually also.

There are also two places in rust-analyzer's coe that might need a fix either, but I'm not sure:

• https://github.com/rust-analyzer/rust-analyzer/blob/93d28fb50c8496d00bfb457a42fb5ee66f83d7b5/crates/ra_lsp_server/src/main_loop/handlers.rs#L592
• https://github.com/rust-analyzer/rust-analyzer/blob/d400fde66c7139aad04e5c5c9875a1d41ef5eae8/crates/ra_cargo_watch/src/lib.rs#L273

[yaymalaga]

@yaymalaga see #2496 (comment).

We had something about this in the install notes, but it was dropped in #3140.

This is precisely what I want to avoid by setting cargo path directly in settings.json, instead of modifying my global PATH.

[rickvanprim]

I would also like to be able to set the cargo path directly in settings.json so that I can make sure Rust Analyzer uses the copy of Rust that's vendored in my workspace instead of trying to use a system installed one.

[yaymalaga]

For my personal needs, the work done as part of #4329 is more than enough.

However, the issue itself is just partially fixed, so I'm not sure if I should close it or keep it opened.

[matklad]

Ok, so I've though about this a bit, and I am still convinced that specific configurations are a wrong approach here. However, I see how it might be awkward to configure env on some OS. So I propose the following solution:

• add rust-analyzer.server.env: Map<string, string> option to configure the environemtn of spawned server
• use this option when spawning the server here: https://github.com/rust-analyzer/rust-analyzer/blob/38e8f35855efac144373c1b5aab3af050e47e594/editors/code/src/client.ts#L16-L19
• change serverPath option here to server.path (idelly, we remove servePath from package.json, but still look at it in config.ts, to have some back compat).

I like this more, because it provides a clear and general mechanism -- overriding env vars.

[rickvanprim]

One issue with solving this via VSCode settings is that VSCode doesn't currently support per platform settings. That's not a rust-analyzer issue, but it does unfortunately block rust-analyzer.server.env from working for my particular use case 😞

[mthebridge]

Ok, so I've though about this a bit, and I am still convinced that specific configurations are a wrong approach here. However, I see how it might be awkward to configure env on some OS. So I propose the following solution:

I like this more, because it provides a clear and general mechanism -- overriding env vars.

There is a related issue that causes me problems, which this would solve: some crates require custom environment variables to be passed to build.rs. For example, using a non-default OpenSSL instance for the openssl-sys crate requires setting various OPENSSL_* environment variables, and at the moment there's no way to tell rust-analyzer to pass these to cargo.

[lnicola]

@yaymalaga we now automatically detect rustc and cargo if they're in ~/.cargo/bin, does it work for you?

(Marking S-actionable, if you look at this in the future and the OP hasn't answered, ping me so we can close it.)

[lnicola]

@mthebridge there's a rust-analyzer.server.extraEnv preference that you can use to set environment variables for the LSP server. It won't care about the OPENSSL_ variables, but cargo should inherit them.

[mthebridge]

@lnicola Ah awesome -thanks, yes, that's exactly what I needed!

[Hecatron]

Hi,
Just to add to the above, I'm currently using rust with an ESP32 board
that requires a custom llvm build of rust for the xtensa-esp32-none-elf target
which isn't part of the standard llvm at the moment

I had a quick go with

    "rust-analyzer.server.extraEnv": {
      "RUSTC": "D:\\SourceCode\\External\\rust-xtensa\\build\\x86_64-pc-windows-msvc\\stage2\\bin\\rustc",
      "RUSTDOC": "D:\\SourceCode\\External\\rust-xtensa\\build\\x86_64-pc-windows-msvc\\stage2\\bin\\rustdoc"
    }

But that didn't seem to work
is there a way of setting / overriding which rustc exe is used by default via a vscode setting?
I don't want to modify my path for it, since it's just the compiler I'm trying to override for this specific project / target

Typically I end up with this otherwise in the problems listing

can't find crate for `core`
the `xtensa-esp32-none-elf` target may not be installed

Edit there is a "rustc" option under .cargo/config so perhaps this setting could be used / picked up from

• https://doc.rust-lang.org/cargo/reference/config.html#configuration-format

[nellshamrell]

Hello all!

I have been looking into this issue as part of Microsoft's Hack Week. I've written up my understanding of the problem along with a potential solution. I would love some feedback on whether my understanding is consistent with the understanding of others as well.

Problem

There is not currently a way to configure rust analyzer to use a specific build of rustc in a VScode project or workspace.

Why would you need to do this?

While a user could specify what version of rustc is used via their PATH environmental variable, that would make it the version of rustc used across their system. A user might be developing using one version of rustc in one project/workspace and a different version in another. It's not ideal to modify their PATH each time they switch projects/workspaces.

Proposed solution

Add a configuration setting to specify a path to a specific build of rustc.

For example, if a user were to add this line to their settings.json file in VSCode:

{"rust-analyzer.build.rustc:" "path/to/rustc/build"}

rust-analyzer would then use that build of rustc for any VSCode project using the same settings.json file.

How to you find out what version of rustc rust-analyzer is using?

It's a bit hacky at the moment, but if you add these print lines to crates/project_model/src/workspace.rs.

And then run this test

It will output the cargo version which (I need to confirm this) should indicate what version of rustc is being used by Rust Analyzer.

[matklad]

Add a configuration setting to specify a path to a specific build of rustc.

I am not a fan of rust-analyzer-specific configuration for rustc version. Presumably, the user would like to compile their project without rust-analyzer as well, so they already have some way to override rustc. We should teach rust-analyzer to use that config, instead of asking the user to configure both ide and command line.

So I’d:

• tried to figure out why RUSTC env var, as above, does not work. It should work, but there maybe some bug
• Check if we can pick up rustc from .cargo/config. If we can’t — fix that as well.

[matklad]

That being said, having client side setting which translates to RUSTC env var might be a good, discoverable addition, after we make sure that all cases that could just work indeed work.

[teohhanhui]

we now automatically detect rustc and cargo if they're in ~/.cargo/bin, does it work for you?

My use case is as such:

• I'm using the flatpak-ed version of vscode: https://github.com/flathub/com.visualstudio.code
• I add ~/.cargo/bin to PATH in ~/.profile and ~/.bashrc, which works for the different shells I need to use, whether on the host, in the flatpak app's environment, or in a toolbox container.
• Unfortunately, I can't find a working way to change the PATH that vscode and its extensions see. Setting the PATH with flatpak override --env doesn't seem to work properly.

So, being able to specify the paths for executables would help (somewhat) in my case. Without this, I'm stuck with https://github.com/flathub/org.freedesktop.Sdk.Extension.rust-stable/

[bjorn3]

You can use rust-analyzer.server.extraEnv to override arbitrary env vars for rust-analyzer.

[yozachar]

Ref: microsoft/vscode#187955

[hadim]

I have a similar need about the path to cargo. Xref with #16204

[Veykril]

I think this is pretty much implemented (given the points raised in the discussions)