Confusing error when forgetting to include system crates in Cargo.toml

[steven807]

Using a crate like rand without adding it to dependencies produces a long message: error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via 'Cargo.toml' instead? (see issue #27812) etc.

This is pretty incomprehensible for a Rust beginner, compared to the normal error when failing to add a dependency:

error[E0463]: can't find crate for `nom`
 --> src/main.rs:1:1
  |
1 | extern crate nom;
  | ^^^^^^^^^^^^^^^^^ can't find crate

Meta

rustc --version --verbose:

% rustc --version --verbose
rustc 1.27.0-nightly (79252ff4e 2018-04-29)
binary: rustc
commit-hash: 79252ff4e25d82f9fe856cb66f127b79cdace163
commit-date: 2018-04-29
host: x86_64-apple-darwin
release: 1.27.0-nightly
LLVM version: 6.0

[ExpHP]

This just showed up here in https://users.rust-lang.org/t/predictable-random-numbers/17593/11?u=exphp for a user trying to use lazy_static. I know this error message has been around in various forms since the stone ages, and I can sort of understand why it arises; but it should be framed first and foremost as a missing crate, not as a use of a nightly feature.

[Mark-Simulacrum]

I'm wondering how we feel about moving the error about rustc_private to a note and having the normal cannot find crate error be displayed? Generally speaking no one who's not working on the compiler cares about loading crates from the sysroot so that seems like a reasonable change.

@rust-lang/compiler, any objections to this? We'd see something like this I imagine:

error[E0463]: can't find crate for `nom`
 --> src/main.rs:1:1
  |
1 | extern crate nom;
  | ^^^^^^^^^^^^^^^^^ can't find crate
  note: nom exists in the sysroot, but this is an unstable location, use #![feature(rustc_private)] to access it.
        You probably want to add `nom` to Cargo.toml instead.

[ExpHP]

What if it didn't mention rustc_private at all for crates.io crates? It seems like enabling this feature for anything that isn't directly part of rustc is such a wildly rare use case that it might as well be relegated to tribal knowledge.

[estebank]

I think that would be reasonable in stable, but it would probably be nice to keep the message in nightly.

[banool]

Any updates here? I'm running into this error as we speak on nightly and it's very unclear what I'm meant to actually do.

In this case it doesn't even point to a crate, but a macro:

error[E0658]: use of unstable library feature 'rustc_private': this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?
 --> src/index.rs:8:10
  |
8 | #[derive(Serialize)]
  |          ^^^^^^^^^

So I don't even know what crate I'm missing.

$ cargo --version
cargo 1.39.0-nightly (3596cb86b 2019-09-19)

The solution was to add a particular crate to my Cargo.toml, but that's not clear from the error.

[zoechi]

@banool I saw this error when I added serde_derive to dependencies, but not serde

[dd-pardal]

This also happens while copying the example lib.rs file from The Rust and WebAssembly Tutorial. This can be fixed by adding cfg-if = "0.1.10" to the [dependencies] table in Cargo.toml.

[drdozer]

Should this be allowed at all? If you accidentally mention something from crates.io that is accidentally on your filesystem but is definitely not in your cargo.toml, should the compiler not just barf, and tell you to add it to cargo? I just got bit by this, and the error message that I needed was "You referenced Deserialize through serde-derive. This is provide by serde, but you have not added serde as a dependency. Add it, fool."