rustc will fallback to libraries distributed with the compiler in presence of --extern

[nagisa]

// test.rs
extern crate libc;
fn main(){}

is the only file in a directory. rustc when invoked like this:

$ rustc test.rs --extern libc=test.rlib
test.rs:1:1: 1:19 error: use of unstable library feature 'libc': use `libc` from crates.io
test.rs:1 extern crate libc;
          ^~~~~~~~~~~~~~~~~~
test.rs:1:1: 1:19 help: add #![feature(libc)] to the crate attributes to enable
error: aborting due to previous error

will still resolve libc to its own liblibc copy rather than fail, as testified by these logs:

…
INFO:rustc::metadata::loader: lib candidate: /usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-11582ce5.rlib
INFO:rustc::metadata::loader: rlib reading metadata from: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-11582ce5.rlib
INFO:rustc::metadata::loader: reading "liblibc-11582ce5.rlib" => 13582ns
…

It should fail with a hard error instead, as if the copy shipped with rustc didn’t exist:

$ rustc test.rs --extern libc2=test.rlib
error: extern location for libc2 does not exist: test.rlib

[steveklabnik]

Triage: this still is true today. Reproduction note: you can get this log by doing RUST_LOG=debug rustc...

[steveklabnik]

Triage: no change

[Enselic]

This issue is about that rustc invalidly will consider its own libc as a candidate for --extern libc=test.rlib.

That was accidentally fixed in nightly-2020-07-31. With nightly-2020-07-30 (the nightly before the fix) we see this:

$ RUSTC_LOG=debug rustc +bisector-nightly-2020-07-30-x86_64-unknown-linux-gnu test.rs --extern libc=test.rlib
[...]
[INFO  rustc_metadata::creader] resolving crate `libc`
[...]
[INFO  rustc_metadata::creader] resolved crates:
[...]
[INFO  rustc_metadata::creader]   name: libc
[INFO  rustc_metadata::creader]   cnum: 6
[INFO  rustc_metadata::creader]   hash: 5cb655619dfdc51f
[INFO  rustc_metadata::creader]   reqd: Explicit
[INFO  rustc_metadata::creader]    rlib: /home/martin/.rustup/toolchains/bisector-nightly-2020-07-30-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-34294dcda38da0eb.rlib
[...]
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?
 --> test.rs:1:1
  |
1 | extern crate libc;
  | ^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #27812 <https://github.com/rust-lang/rust/issues/27812> for more information
  = help: add `#![feature(rustc_private)]` to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.

It is clear that libc is resolved wrongly. Both based on the debug log and based on the emitted user-facing error message. With nightly-2020-07-31 we instead see this:

$ RUSTC_LOG=debug rustc +bisector-nightly-2020-07-31-x86_64-unknown-linux-gnu test.rs --extern libc=test.rlib
[...]
[INFO  rustc_metadata::creader] resolving crate `libc`
[INFO  rustc_metadata::creader] falling back to a load
error: extern location for libc does not exist: test.rlib
 --> test.rs:1:1
  |
1 | extern crate libc;
  | ^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

We can see both that the error changed, and that the resolver failed to resolve libc at all. Given that we know in what nightly this changed, it most likely is #74915 that accidentally fixed #26043.

We need a regression test before we can close this.

@rustbot label E-needs-test