rust-analyzer: "cargo metadata failed: No such file or directory (os error 2)"
I’m trying to work on a project that the RLS extension has no problem handling but I’m getting an odd error from rust-analyzer that is pretty unhelpful:
rust-analyzer failed to load workspace: cargo metadata failed: No such file or directory (os error 2)
What file or directory could not be found? Why couldn’t it be found even though RLS works without a hitch?
I’m running the VSCode extension remotely (Docker) with VSCode Insiders and rust-analyzer at commit 759100fb0dcb41518f2a593dae5de5bbedd07776.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 68 (38 by maintainers)
Commits related to this issue
- ra_project_model: look for Cargo in more places See #3118 — committed to cdisselkoen/rust-analyzer by cdisselkoen 4 years ago
- ra_project_model: look for Cargo in more places See #3118 — committed to cdisselkoen/rust-analyzer by cdisselkoen 4 years ago
- ra_project_model: look for Cargo in more places See #3118 — committed to cdisselkoen/rust-analyzer by cdisselkoen 4 years ago
- Merge #4329 4329: Look for `cargo`, `rustc`, and `rustup` in standard installation path r=matklad a=cdisselkoen Discussed in #3118. This is approximately a 90% fix for the issue described there. ... — committed to rust-lang/rust-analyzer by bors[bot] 4 years ago
@marcogroppo Yes, I can
cargoandrustcwithout a problem. They’re included in my PATH via.zshrc:Not sure if it matters that I’m using zsh…
This is also an issue on macOS, where there’s no trivial way to set environment variables for GUI apps.
This is interesting. RLS depends on cargo as a package. I suppose they don’t use
cargocli then…?Related stackoverflow question on why this is an issue for Mac users that is not as easy to fix as on Linux or Windows: https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x
Actually I’m already working on a fix
Adding that line to the end of my
.profile(which I know is executed by my shell) did not solve the problem for me, but the launching-from-terminal workaround does.Regardless, if someone wants to actually fix this in rust-analyzer, I’ll remind people that @matklad (primary maintainer here IIUC) commented farther above in this thread that
I imagine this wouldn’t be terribly difficult to make a PR for. Maybe I’ll get around to making a PR for this soon.
Archlinux 5.5.13 rustc 1.42.0 cargo 1.42.0 emacs 27.0.9
Also got same error when trying to use emacs daemon. I added a PATH env var to my systemd service file to ensure it found cargo and seems to have fixed it for me.
note - on exact same Rust project, I didn’t get this error if I ran emacs alone (without the daemon).
`[Unit] Description=Emacs: the extensible, self-documenting text editor Documentation=man:emacs(1) info:Emacs
[Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval “(progn (setq kill-emacs-hook nil) (kill-emacs))” Restart=on-failure Environment=DISPLAY=:%i Environment=HOME=/home/wayc Environment=PATH=/home/wayc/.cargo/bin:/usr/local/bin:/usr/bin:/bin TimeoutStartSec=0
[Install] WantedBy=default.target `
Got it working, thanks! Ended up just creating a wrapper script and launched that from the custom
.desktopfile saved to~/.local/share/applications/Is rustc in PATH for the proceeds which starts the server?
On Wednesday, 4 March 2020, GuzTech notifications@github.com wrote:
I think you can set environment variables in the Dockerfile? Our at least in devcontainer.json.