Skip to content

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

Closed
@jyn514

Description

@jyn514
Member

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

Activity

added
E-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.
T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
C-bugCategory: This is a bug.
on Mar 5, 2023
KittyBorgX

KittyBorgX commented on Mar 7, 2023

@KittyBorgX
Member

@rustbot claim

removed their assignment
on Mar 16, 2023
jyn514

jyn514 commented on Apr 9, 2023

@jyn514
MemberAuthor

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

jyn514 commented on Apr 9, 2023

@jyn514
MemberAuthor

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

jyn514 commented on Apr 9, 2023

@jyn514
MemberAuthor

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.

added
A-metadataArea: Crate metadata
A-testsuiteArea: The testsuite used to check the correctness of rustc
on Apr 9, 2023
self-assigned this
on Apr 9, 2023

17 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-download-rustcArea: The `rust.download-rustc` build option.A-metadataArea: Crate metadataA-testsuiteArea: The testsuite used to check the correctness of rustcC-bugCategory: This is a bug.E-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Participants

    @jyn514@KittyBorgX

    Issue actions

      `tests/ui/allocator/no_std-alloc-error-handler*` fail when `download-rustc` is enabled · Issue #108767 · rust-lang/rust