user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rollup merge of #151002 - remove_bug_workaround, r=lqd

Browse source 
Remove a workaround for a bug (take 2)

I don't think it is necessary anymore. As I understand it from issue 39504 the original problem was that rustbuild changed a hardlink in the cargo build dir to point to copy in the sysroot while cargo may have hardlinked it to the original first. I don't think this happens anymore and as such this workaround is no longer necessary

I can't reproduce the CI failure in https://github.com/rust-lang/rust/pull/122186 locally with `./x.py test library/core`. It is possible this got fixed by https://github.com/rust-lang/rust/pull/149273.
This commit is contained in:
Jonathan Brouwer 2026-01-13 09:01:33 +01:00 • committed by GitHub
commit 6e2d304223
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 0 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

29
compiler/rustc_metadata/src/locator.rs
View file

@ -242,7 +242,6 @@ use crate::rmeta::{METADATA_HEADER, MetadataBlob, rustc_version};
pub(crate) struct CrateLocator<'a> {
// Immutable per-session configuration.
only_needs_metadata: bool,
sysroot: &'a Path,
metadata_loader: &'a dyn MetadataLoader,
cfg_version: &'static str,
@ -318,7 +317,6 @@ impl<'a> CrateLocator<'a> {
CrateLocator {
only_needs_metadata,
sysroot: sess.opts.sysroot.path(),
metadata_loader,
cfg_version: sess.cfg_version,
crate_name,
@ -670,33 +668,6 @@ impl<'a> CrateLocator<'a> {
continue;
}
// Ok so at this point we've determined that `(lib, kind)` above is
// a candidate crate to load, and that `slot` is either none (this
// is the first crate of its kind) or if some the previous path has
// the exact same hash (e.g., it's the exact same crate).
//
// In principle these two candidate crates are exactly the same so
// we can choose either of them to link. As a stupidly gross hack,
// however, we favor crate in the sysroot.
//
// You can find more info in rust-lang/rust#39518 and various linked
// issues, but the general gist is that during testing libstd the
// compilers has two candidates to choose from: one in the sysroot
// and one in the deps folder. These two crates are the exact same
// crate but if the compiler chooses the one in the deps folder
// it'll cause spurious errors on Windows.
//
// As a result, we favor the sysroot crate here. Note that the
// candidates are all canonicalized, so we canonicalize the sysroot
// as well.
if let Some(prev) = &ret {
let sysroot = self.sysroot;
let sysroot = try_canonicalize(sysroot).unwrap_or_else(|_| sysroot.to_path_buf());
if prev.starts_with(&sysroot) {
continue;
}
}
// We error eagerly here. If we're locating a rlib, then in theory the full metadata
// could still be in a (later resolved) dylib. In practice, if the rlib and dylib
// were produced in a way where one has full metadata and the other hasn't, it would