-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/ui/allocator/no_std-alloc-error-handler*
fail when download-rustc
is enabled
#108767
Comments
@rustbot claim |
Ok, it turns out both versions are coming from CI:
I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing. |
The difference between this test and others is that somehow in other tests
for the allocator tests, it doesn't know, and gives an ambiguity error:
|
ok, here's a minimal reproducer:
I think what's going on is for the working tests, the implicit
Then, when the compiler sees 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. |
…tlarsan68 Fix no_std tests that load libc from the sysroot when download-rustc is enabled There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` 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 ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; 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 ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true` and some tool depends on a local change to `compiler`. --- See rust-lang#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang#108767.
Fix no_std tests that load libc from the sysroot when download-rustc is enabled There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` 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 rust-lang#2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; 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 ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang/rust#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true` and some tool depends on a local change to `compiler`. --- See rust-lang/rust#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang/rust#108767.
Copying files from `.rustc-dev-contents` regressed rust-lang#108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component in the sysroot. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Copying files from `.rustc-dev-contents` regressed rust-lang#108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component in the sysroot. Signed-off-by: onur-ozkan <work@onurozkan.dev>
Since rust-lang#127188, copying files from `.rustc-dev-contents` regressed rust-lang#108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component. Signed-off-by: onur-ozkan <work@onurozkan.dev>
…, r=Kobzol don't copy `.rustc-dev-contents` from CI rustc Since rust-lang#127188, copying files from `.rustc-dev-contents` regressed rust-lang#108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component. Blocker for rust-lang#122709
Rollup merge of rust-lang#129311 - onur-ozkan:multiple-candidates-fix, r=Kobzol don't copy `.rustc-dev-contents` from CI rustc Since rust-lang#127188, copying files from `.rustc-dev-contents` regressed rust-lang#108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component. Blocker for rust-lang#122709
…tiple-candidates, r=Kobzol skip in-tree compiler build for llvm-bitcode-linker if ci-rustc is on Similar to rust-lang#108767, resolves the `multiple candidates` problem for ci-rustc. See rust-lang#122709 (comment) for more context. Blocker for rust-lang#122709.
Rollup merge of rust-lang#130479 - onur-ozkan:llvm-bitcode-linker-multiple-candidates, r=Kobzol skip in-tree compiler build for llvm-bitcode-linker if ci-rustc is on Similar to rust-lang#108767, resolves the `multiple candidates` problem for ci-rustc. See rust-lang#122709 (comment) for more context. Blocker for rust-lang#122709.
cc #81930
I tried this:
I expected to see this happen: The tests pass.
Instead, this happened: The tests fail:
These tests are pretty complicated but the error message looks correct:
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 thatrustc-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 fromensure(compile::Std)
somewhere - maybe we should clear therustlib/
directory before doing that?Meta
HEAD is 35636f9
The text was updated successfully, but these errors were encountered: