Description
The rust-src
component that gets installed by Rustup to ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust
includes a Cargo.lock
that spans the standard library crates, but does not include a corresponding Cargo.toml
(essentially this Cargo.toml
).
Cargo's -Zbuild-std
feature makes this work anyway by constructing a virtual workspace for the standard library, but this doesn't work for editors that want to provide users with completion and analysis all the way into std
/alloc
/core
. They end up running cargo metadata
directly in the various standard library crates (library/std
for example) (IntelliJ, rust-analyzer). However, since there's no workspace-level Cargo.toml
next to the Cargo.lock
, they do not pick up on the locked versions at all, and instead use whatever the latest versions of the standard library's dependencies are. This in turn means that go-to-definition and similar mechanisms do not go to the actual versions used by the standard library the user is actually using.
In chatting to @Mark-Simulacrum about this, I think the editors are arguably doing the right thing here by running cargo metadata
inside the individual crates (like std), and Cargo is doing the right thing not looking at the Cargo.lock
since there isn't a workspace there. And it feels like the right thing to do is to synthesize a workspace Cargo.toml
for inclusion with rust-src
. But if we explicitly won't (or can't) include a Cargo.toml
in rust-src
's root, we have a couple of options:
- We could maybe special-case Cargo to recognize when it's run on a crate from within the standard library.
cargo metadata
could have something like--with-lockfile Cargo.lock
so that you can run it in arbitrary places on disk while pointing to (for example) a checked out repositoriesCargo.lock
.- We could change Cargo to always include std + deps in everyone's
Cargo.lock
as some kind of special dep kind. - We could create
cargo metadata --include-std
.
All of these feel brittle to one extent or another though, and it's not clear that they are sufficient for what editors may need (cc @matklad), so I think we should push for including Cargo.toml
if we can.
Meta
rustc --version --verbose
:
rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-unknown-linux-gnu
release: 1.59.0
LLVM version: 13.0.0