rust analyzer: Failed to load workspaces after opening stdlib and restarting

[Matt3o12]

Summary

rust analyzer: Failed to load workspaces is shown if I open the stdlib from my project and restart zed.

Description

The error message inside the language server is:

click to expand

2025-05-08T18:55:21.682301094+02:00 ERROR FetchWorkspaceError: rust-analyzer failed to load workspace: Failed to load the project at /home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml: Failed to read Cargo metadata from Cargo.toml file /home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml, Some(Version { major: 1, minor: 86, patch: 0 }): Failed to run `cd "/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std" && RUSTUP_TOOLCHAIN="/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu" "/home/parallels/.cargo/bin/cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml" "--filter-platform" "aarch64-unknown-linux-gnu"`: `cargo metadata` exited with an error: error: failed to parse manifest at `/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml`

Caused by:
  the cargo feature `public-dependency` requires a nightly version of Cargo, but this is the `stable` channel
  See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
  See https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency for more information about using this feature.


2025-05-08T18:55:21.857844844+02:00 ERROR FetchWorkspaceError: rust-analyzer failed to load workspace: Failed to load the project at /home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml: Failed to read Cargo metadata from Cargo.toml file /home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml, Some(Version { major: 1, minor: 86, patch: 0 }): Failed to run `cd "/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std" && RUSTUP_TOOLCHAIN="/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu" "/home/parallels/.cargo/bin/cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml" "--filter-platform" "aarch64-unknown-linux-gnu"`: `cargo metadata` exited with an error: error: failed to parse manifest at `/home/parallels/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/Cargo.toml`

Caused by:
  the cargo feature `public-dependency` requires a nightly version of Cargo, but this is the `stable` channel
  See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
  See https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency for more information about using this feature.

Steps to reproduce:

1. Create a new project
2. Open the stdlib (for example by importing Path and cmd clicking on it)
3. Restart zed
4. See error message:

Expected Behavior: No error Actual Behavior: Error message

This is reproducable on the latest zed version. I noticed it on my mac and to reproduce it, I even installed zed on a fresh fedora vm w/o any modifications to any settings (I only ran installed zed and rustup).

Zed Version and System Specs

Zed System Specs (from CLI): Zed: v0.185.13 (Zed) OS: Linux Wayland fedora 40 Memory: 5.7 GiB Architecture: aarch64 GPU: Failed to run vulkaninfo --summary

[Matt3o12]

@SomeoneToIgnore can you explain why you think this is a duplicate of #20767 ? My bug seems to be completely unrelated to the other one, except that both involve restarting zed. My issue is even 100% reproducable.

[SomeoneToIgnore]

https://github.com/zed-industries/zed/issues/20767#issuecomment-2615816849 covers that in detail, mentioning the exact same scenario: some "detached" (e.g. stdlib) worktrees are handled quite badly.

Part of that handling results in Zed restarting with such detached worktrees, and spawning language severs badly, which causes errors like mentioned above.