FetchWorkspaceError in VSCode extension on Arch Linux

[dainbrump]

OS: Arch Linux DE: KDE 6 VSCode about details: Version: 1.95.3 Commit: f1a4fb101478ce6ec82fe9627c43efbf9e98c813 Date: 2024-11-13T14:50:04.152Z Electron: 32.2.1 ElectronBuildId: 10427718 Chromium: 128.0.6613.186 Node.js: 20.18.0 V8: 12.8.374.38-electron.0 OS: Linux x64 6.11.6-zen1-1-zen

I am not using the flatpak edition.

rust-analyzer version: 0.3.2188-standalone - reported by VSCode

rustc 1.82.0 (f6e511eec 2024-10-15) cargo 1.82.0 (8f40fc59f 2024-08-21)

echo $CARGO_HOME ~/.local/share/cargo

echo $RUSTUP_HOME ~/.local/share/rustup

I have tried everything imaginable and everything that has been suggested to get past this error and variations on the same message that I have been able to dig up through Google. I even went so far as to ask Gemini if I was missing something.

The error message as reported in VSCode log output for rust-analyzer: ERROR FetchWorkspaceError: rust-analyzer failed to load workspace: Failed to load the project at ~/{path to my Rust project}/Cargo.toml: Failed to query rust toolchain version at ~/{path to my Rust project}, is your toolchain setup correctly?: cd "~/{path to my Rust project}" && "cargo" "--version" failed: No such file or directory (os error 2)

I have tried the following:

• Going to the directory and running "cargo --version" both in VSCode terminal and my system terminal. Both worked.
• Uninstalled, verified all remnants were removed and resinstalled rust stable toolchain using the rustup recommended curl script.
• Uninstalled and reinstalled VSCode, ensuring all extensions, etc were removed.
• Deactivated all other extensions to eliminate possible contamination from another extension.
• Verified that I don't have any oddball configuration settings in VSCode.
• Verified I have path access to all rust binaries - cargo, rustc, rust-analyzer, etc - from inside VSCode terminal.
• Closed and relaunched VSCode too many times to count.
• Verified I have no outstanding system updates and rebooted several times between making various changes to try and solve this one issue.
• Set the default toolchain with rustup default stable
• Set the languageServer path in VSCode settings.
• Checked for linkedProjects settings. Removed them, added them, used relative paths, used full paths.
• Pulled hair out and consumed whiskey. Not sure why, but this was recommended at some point and it made me feel better briefly.

What I am left with is that I have completely removed Rust (rustup self uninstall), completely removed VSCode (extensions and all), rebooted, reinstalled rust using the curl script, reinstalled VSCode and ONLY the rust-analyzer extension (I don't even have a custom theme set), created a completely brand new Rust project with cargo new, went into that directory from my terminal and launched VSCode with code . and... I STILL SEE THIS BLOODY ERROR!

I apologize if it seems like a rave and rant. I am at wits ends and cannot think of any other troubleshooting step that I haven't already done at least twice.

[lnicola]

This might be a bug, but it sounds like you're a little frustrated with this. If it helps for the moment, it's almost certainly caused by your CARGO_HOME and RUSTUP_HOME.

[dainbrump]

This might be a bug, but it sounds like you're a little frustrated with this. If it helps for the moment, it's almost certainly caused by your CARGO_HOME and RUSTUP_HOME.

Hmm. Something for me to investigate. Do I only need one or the other? I spent quite a bit of time trying to clean up my dotfiles and get everything I could to use the XDG paths... at least the things that would. I found the CARGO_HOME and RUSTUP_HOME variables in a list in an Arch wiki or something similar. The listing didn't really specify much about when to use one or the other. I'll dig around again and see if I can find it.

I did have an interesting discovery. I tried a complete clean and reinstall of Rust and VSCode again. Then I went to my fresh Rust project in my terminal and ran code . Suddenly rust-analyzer started working. However, if I open VSCode from the app launcher and open that folder, I get that error message. It's almost as if none of my environment variables are being loaded in KDE or shared with launched apps or something. Not entirely sure what's going on there. Any thoughts on that?

[lnicola]

It's almost as if none of my environment variables are being loaded in KDE or shared with launched apps or something.

They aren't, but I didn't mention that because you were already running Code from the terminal.

[dainbrump]

Culprits found and behold they are yet again Wayland and systemd.

I had all of my XDG vars, other environment vars and PATH set between my .profile, .bash_profile and .bashrc accordingly as one would normally do. However, KDE with Wayland (not sure if it's just the Wayland aspect or if KDE is going this route also) does not load the .profile data. In order to have those variables loaded, one must use the systemd way of doing things. I tested this by running systemctl --user set-environment CARGO_HOME="{my path to cargo home}" where the path is the full path - not relying on XDG or $HOME shortcuts. I repeated that step for RUSTUP_HOME and my PATH statement to include the cargo bin path. Logged out and back in. Suddenly rust-analyzer in VSCode works when I launch from the app launcher.

The final fix for me was:

1. Create a new file under ~/.config/environment.d/ named 10-env-vars.conf
2. Copy the contents of my .profile file into that new file. My .profile contains 90% of the environment variables I use and is typically sourced from my .bashrc.
3. Remove any lines in the new file that didn't export an environment variable.
4. Remove the export statement from those lines that remained.
5. Find/Replace any path variables like $XDG_CONFIG_HOME with their full path equivalents.
6. Review the final result for proper double-quote wraps.
7. Save and reboot.

Once I logged into KDE, I launched VSCode from the launcher and loaded my project. Rust-analyzer began working like a champ.

This may be something to look at as part of the installer script. If a user is using systemd and / or Wayland, instead of just tacking on the path and any other variables to the .bashrc / .profile, have the script run the appropriate systemctl --user set-environment command to inject the values into the users desktop environment.

I think we can close this.

[lnicola]

It's neither systemd, nor Wayland. Your DE isn't a shell script, so it doesn't source any of the shell rc files. systemd offers a solution to this in the form of ~/.config/environment.d.