Vscode rust-analyzer without (local) rustc?

Hi, I'm using vscode on a corporate windows 10 laptop which allows me to create VMs but not install rustc natively.

Is it possible to configure rust-analyzer so that it does not require a local install of rustc?

I'm seeing errors like the following in the Rust Analyzer Language Server's output (irrelevant paths replaced by [italics] ):

[ERROR rust_analyzer::main_loop] FetchWorkspaceError:

rust-analyzer failed to load workspace: Failed to load the project at [project]\Cargo.toml: Failed to query rust toolchain version at [path], is your toolchain setup correctly?: "cargo" "--version" failed: program not found

Currently using
rust-analyzer v0.3.1705,
vscode v1.83.1

you don't need administrator privilege to install rust toolchain. you just need a local directory that is writable. you can set RUSTUP_HOME and CARGO_HOME envvar. see Installation - The rustup book

I believe rust-analyzer itself can work without rustc, but it's not practical to use it this way. typically, rust-analyzer asks cargo to print the metadata for the codebase. if you don't have rust toolchain installed, you will need to provide the metadata manually. also, without a local standard library component, rust-analyzer cannot index and provide code actions for standard library.

that being said, I assume hyper-v is available, right? can you install wsl2? you can use vscode under wsl seamlessly.

otherwise, you can always using a Linux VM as a vscode remote server using ssh remote.

If you are using VS Code, you should be able to run the compiler and everything else inside a dev container or through a SSH connection to a VM.

Sadly this is not about privileges. It's about not installing stuff which has not been approved at corporate level, which in this case means not installing rustc or wsl2. I can create a Linux VM (and probably will) but at the moment I just want to use my existing vscode to look at syntax-coloured rust code.

understandable. different corporations have different policies.

a wsl2 distro is a VM (with special host interop services). but it all depends on your company's requirement after all.

then you don't need rust-analyzer, or lsp at all, the default tree-sitter based syntax highlight works just fine. it's just not as accurate as semantics token based highlight, and you don't have the code navigation functionality like jump to definition etc., but the syntax highlight works out of the box.

Thanks for pointing out that I don't really need rust-analyzer right now.

The rest is an observation on the nature of a wsl2 distro vs a 'normal' VM which I hope provides a different perspective on it.

This is broadly true, but it's those host interop services which are the sticking point: it's a VM which gives 'non-windows executables of unknown provenance' broad access to the host's file systems.

(Unknown provenance from a windows point of view, that is.)

Those same non-windows executables in a 'normal' VM cannot by default access host files, which significantly reduces the available attack surface affecting the host.

When I want the VM to share files with the host, I have to make sure the root of the shared folder is effectively a leaf folder, so that only the files below that folder are accessible to the VM.

yeah, wsl is definitely different from a "normal" VM in terms of security.

as the name suggests, wsl is really meant to be a "subsystem" of the host system. the fact wsl2 is implemented as a hyper-v guest VM is just to ensure binary compatibility, since a real Linux kernel is used (as opposed to wsl1 where Linux syscalls are emulated in the host NT kernel).

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.