Fix no_std tests that load libc from the sysroot when download-rustc is enabled#110229
Fix no_std tests that load libc from the sysroot when download-rustc is enabled#110229bors merged 1 commit intorust-lang:masterfrom
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
|
Hmm, this breaks |
78c8765 to
5822660
Compare
|
Ok, pushed a fix. |
This comment was marked as resolved.
This comment was marked as resolved.
5822660 to
140db1c
Compare
|
What happens if there is a step that needs the Rustc sysroot, then another doesn't need one? What if a first x invocation copies the files, then a second needs them not to be here? |
|
x runs these tests in a pre-determined order that isn't affected by the order of the command line arguments: Lines 694 to 707 in 1e95cdd So if there is a new Step that requires not having I think this is the same as how things normally work even when |
|
I was thinking of the case where you run something that needs full sysroot, then in a second command something that needs the less full sysroot. Is there a second sysroot created, are the unneeded files deleted, or does everything break? |
|
Bootstrap deletes and recreates the sysroot each time it's invoked: Line 1263 in 18109d5 So artifacts that were copied in a previous run can't affect the next run. |
|
r=me with a comment specifying this quirk |
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`. --- 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.
140db1c to
71f04bd
Compare
|
@bors r=albertlarsan68 rollup=iffy |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (da48140): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since #110229, but the fix didn't account for sysroot crates. Should fix #147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since #110229, but the fix didn't account for sysroot crates. Should fix #147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since #110229, but the fix didn't account for sysroot crates. Should fix #147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since #110229, but the fix didn't account for sysroot crates. Should fix #147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…=petrochenkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang#110229, but the fix didn't account for sysroot crates. Should fix rust-lang#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
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):Before, this would give an error about duplicate versions of libc:
Both these versions were downloaded from CI, but one came from the
rust-stdcomponent and one came fromrustc-dev:The fix was to only copy files from
rust-stdunless a Step explicitly requests for therustc-devcomponents to be available by callingbuilder.ensure(compile::Rustc).To avoid having to re-parse the
rustc-dev.tar.xztarball every time, which is quite slow, this adds a newbuild/host/ci-rustc/.rustc-dev-contentscache file which stores only the names of files we need to copy into the sysroot.This also allows reverting the hack in #110121; now that we only copy rustc-dev on-demand, we can correctly add the
Rustccheck artifacts into the sysroot, so that this works correctly even whendownload-rustcis forced totrueand some tool depends on a local change tocompiler.See #108767 (comment) for why
no_stdis required for the MCVE test to fail; it's complicated and not particularly important.Fixes #108767.