Skip to content

rust-src does not include workspace Cargo.toml #95736

Closed
@jonhoo

Description

@jonhoo

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 repositories Cargo.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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions