`tests/ui/allocator/no_std-alloc-error-handler*` fail when `download-rustc` is enabled

[jyn514]

cc #81930

I tried this:

x test tests/ui/allocator/no_std-alloc-error-handler*

I expected to see this happen: The tests pass.

Instead, this happened: The tests fail:

Check compiletest suite=ui mode=ui (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)

running 22 tests
iiiiiiiiiiiiiiiiiiiiFF
failures:

---- [ui] tests/ui/allocator/no_std-alloc-error-handler-default.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit status: 1
command: "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/home/gh-jyn514/rust/tests/ui/allocator/no_std-alloc-error-handler-default.rs" "-Zthreads=1" "--target=aarch64-unknown-linux-gnu" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=/home/gh-jyn514/rust/tests/ui=fake-test-src-base" "-C" "prefer-dynamic" "-o" "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/test/ui/allocator/no_std-alloc-error-handler-default/a" "-Crpath" "-Cdebuginfo=0" "-Lnative=/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/test/ui/allocator/no_std-alloc-error-handler-default/auxiliary" "-C" "panic=abort"
stdout: none
--- stderr -------------------------------
error[E0464]: multiple candidates for `rlib` dependency `libc` found
  --> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1
   |
LL | extern crate libc;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib
   = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta

error: aborting due to previous error

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


---- [ui] tests/ui/allocator/no_std-alloc-error-handler-custom.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit status: 1
command: "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/home/gh-jyn514/rust/tests/ui/allocator/no_std-alloc-error-handler-custom.rs" "-Zthreads=1" "--target=aarch64-unknown-linux-gnu" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=/home/gh-jyn514/rust/tests/ui=fake-test-src-base" "-C" "prefer-dynamic" "-o" "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/test/ui/allocator/no_std-alloc-error-handler-custom/a" "-Crpath" "-Cdebuginfo=0" "-Lnative=/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/test/ui/allocator/no_std-alloc-error-handler-custom/auxiliary" "-C" "panic=abort"
stdout: none
--- stderr -------------------------------
error[E0464]: multiple candidates for `rlib` dependency `libc` found
  --> fake-test-src-base/allocator/no_std-alloc-error-handler-custom.rs:16:1
   |
LL | extern crate libc;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib
   = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta

error: aborting due to previous error

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



failures:
    [ui] tests/ui/allocator/no_std-alloc-error-handler-custom.rs
    [ui] tests/ui/allocator/no_std-alloc-error-handler-default.rs

test result: FAILED. 0 passed; 2 failed; 20 ignored; 0 measured; 14535 filtered out; finished in 0.13s

These tests are pretty complicated but the error message looks correct:

error[E0464]: multiple candidates for `rlib` dependency `libc` found
  --> fake-test-src-base/allocator/no_std-alloc-error-handler-custom.rs:16:1
   |
LL | extern crate libc;
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib
   = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta

I'm not sure why both files are there and particularly why they have different hashes. tar -tf build/cache/35636f9459720513ca4ed19373a4a7c9e0ea3c46//rustc-dev-nightly-aarch64-unknown-linux-gnu.tar.xz | grep liblibc shows that
rustc-dev-nightly-aarch64-unknown-linux-gnu/rustc-dev/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta is being downloaded from CI, and I guess the .rlib is coming from ensure(compile::Std) somewhere - maybe we should clear the rustlib/ directory before doing that?

Meta

HEAD is 35636f9

[KittyBorgX]

@rustbot claim

[jyn514]

Ok, it turns out both versions are coming from CI:

; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc
rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta

I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.

[jyn514]

The difference between this test and others is that somehow in other tests rustc_resolve knows ahead of time which hash it should use:

INFO rustc_metadata::creader resolving dep crate libc hash: `75267ce7b5b7c8d8` extra filename: `-68a2d9e195dd6ed2`
INFO rustc_metadata::creader resolving crate `libc`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
INFO rustc_metadata::locator rlib reading metadata from: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
INFO rustc_metadata::creader register crate `libc` (cnum = 6. private_dep = false)

for the allocator tests, it doesn't know, and gives an ambiguity error:

INFO rustc_metadata::creader resolving crate `libc`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
INFO rustc_metadata::locator lib candidate: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta
INFO rustc_metadata::locator rmeta reading metadata from: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta
INFO rustc_metadata::locator rlib reading metadata from: /home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib
INFO rustc_metadata::creader resolving crate `core`
error[E0464]: multiple candidates for `rlib` dependency `libc` found

[jyn514]

ok, here's a minimal reproducer:

#![crate_type = "lib"]
#![no_std]
#![feature(rustc_private)]
extern crate libc;

I think what's going on is for the working tests, the implicit extern crate std injected by the compiler also loads libc, because std depends on libc:

; cargo tree -p std -i libc --depth 1
libc v0.2.140
├── panic_abort v0.0.0 (/home/jyn/src/rust2/library/panic_abort)
├── std v0.0.0 (/home/jyn/src/rust2/library/std)

Then, when the compiler sees extern crate libc, it's already seen the version std depends on and resolves the ambiguity by reusing that crate.

But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.