Rust-analyzer raises an error when opening a project in WSL2

[alicika]

I have my rust development environment on top of WSL2 (kali-linux). After installing rust-analyzer from the marketplace in VSCode, I got this error on the hovering toast so that I cannot go forward.
rust-analyzer failed to load workspace: No such file or directory (os error 2)

Does the problem happen because rust toolchain is built on WSL2? If so, how do I solve it?
I've done a preliminary search about some relevant issues but I cannot find the answer yet.

Thanks in advance.

DESKTOP-J74E4AM$ cargo --version
cargo 1.55.0 (32da73ab1 2021-08-23)

DESKTOP-J74E4AM$ rustc --version
rustc 1.55.0 (c8dfcfe04 2021-09-06)

DESKTOP-J74E4AM$ uname -a
Linux DESKTOP-J74E4AM 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 GNU/Linux

My VSCode setup:

Version: 1.62.3 (user setup)
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-17T08:11:14.551Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19042

My rust-analyzer version:

rust-analyzer version: d9b2291f5 2021-11-29 stable

[lnicola]

When VS Code Remote is started in WSL, no shell startup scripts are run. This was done to avoid issues with startup scripts that are tuned for shells. If you want to run additional commands or modify the environment this can be done in a setup script ~/.vscode-server/server-env-setup (Insiders: ~/.vscode-server-insiders/server-env-setup). If present, the script is processed before the server is started.

The script needs to be a valid Bourne shell script. Be aware that an invalid script will prevent the server from starting up. If you end up with a script that prevents the server from starting, you will have to use a regular WSL shell and delete or rename the setup script.

Not sure, it's possible that cargo isn't in your PATH on the remote side. If you open a terminal in VS Code and type cargo, does it work?

[alicika]

Seems like there's no problem with the PATH. I just have the rust toolchain installed on remote Kali-Linux side, not on the host Windows side.

DESKTOP-J74E4AM$ cargo
Rust's package manager

USAGE:
    cargo [+toolchain] [OPTIONS] [SUBCOMMAND]

OPTIONS:
    -V, --version                  Print version info and exit
        --list                     List installed commands
### omitted the rest

DESKTOP-J74E4AM$ printenv
PATH=/home/umaaji/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:... ### omitted the rest

[lnicola]

Try:

$ ps aux | grep code # vscode-server or something like that
$ cat /proc/PID_OF_CODE_SERVER/environ | tr '\000' $'\n' | grep PATH

And same thing with the rust-analyzer process (there will be two of them you can pick the one without proc-macro in the command line).

[alicika]

DESKTOP-J74E4AM$ ps aux | grep code
umaaji    1275  0.0  0.0   6252  2128 pts/0    S+   23:26   0:00 grep --color=auto code

It seems like it just shows me the executed grep itself. Here are the entire results of running grep, for information.

DESKTOP-J74E4AM$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   1056   516 ?        Sl   Nov30   0:16 /init
root       626  0.0  0.0   1404   472 ?        Ss   02:29   0:00 /init
root       627  0.0  0.0   1404   472 ?        S    02:29   0:00 /init
umaaji     628  0.0  0.1   7032  3716 pts/0    Ss   02:29   0:01 -bash
umaaji    1281  0.0  0.1   9852  3328 pts/0    R+   23:31   0:00 ps aux

[lnicola]

Are you running that in the Code terminal?

[alicika]

I'm not completely sure, but I believe I'm running it in VSCode's internal WSL window.
Am I doing it the wrong way?

[lnicola]

Yeah, I'm not on WSL, but with SSH it looks like this:

[alicika]

While investigating as I change situations, I feel like I found where they happen.
It seems that the rust-analyzer works as expected when WSL2 is launched with a remote connection, but the error occurs when the WSL2 shell is launched without that. I have no idea how these two are different (except text in the left-below corner), but the error message doesn't correctly refer to the context in which it is shown.
Could I ask for an improvement for the error message?

[zerocity]

Hi i had a simmilar problem with WSL
I could not start the rust-analyzer

➜  uname -a
Linux DESKTOP-GCH8R3L 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
➜  matklad.rust-analyzer-0.2.964 server/rust-analyzer --version
server/rust-analyzer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by server/rust-analyzer)
➜  matklad.rust-analyzer-0.2.964 ..
➜  extensions matklad.rust-analyzer-0.3.963/server/rust-analyzer
matklad.rust-analyzer-0.3.963/server/rust-analyzer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by matklad.rust-analyzer-0.3.963/server/rust-analyzer)

https://askubuntu.com/questions/1021420/glibc-2-25-not-found-on-ubuntu-windows-subsystem-for-linux

[lnicola]

@zerocity which distro is that? (see /etc/os-release)? CC #11808

[zerocity]

NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

i was thinking i had a newer version ....

ok sorry i found the correct issue 🙈

#11558

[RichardB613]

While investigating as I change situations, I feel like I found where they happen. It seems that the rust-analyzer works as expected when WSL2 is launched with a remote connection, but the error occurs when the WSL2 shell is launched without that. I have no idea how these two are different (except text in the left-below corner), but the error message doesn't correctly refer to the context in which it is shown. Could I ask for an improvement for the error message?

VScode seems to use the default windows hosts terminal(cmd) unless you remote into WSL2. Tthe other option is to install rust on Windows itself rather than WSL2.