rustc: Prefer loading crates in the sysroot

alexcrichton · alexcrichton · commit 6f431491d0c9 · 2017-03-09T07:00:13.000-08:00
This commit is a random stab in the dark to fix the spurious failures on #39518. The leading theory of the spurious failures on Windows is that the compiler is loading a path in the `deps` folder, passing it to `link.exe`, and then this is racing with Cargo itself updating those paths. This race, however, has a few unique properties: * It's isolated to just libstd. Most crates are never passed to the linker and simultaneously being worked on by Cargo. Cargo's typical execution of the dependency graph never hits this problem. * The crates are already all located in the sysroot in addition to the `deps` folder. This means that the compiler actually has two candidates of crates to load, and it's just arbitrarily rejecting one. Together this means that we shouldn't need to fix this problem "in the large" and we can instead just fix it in this isolated situation (hopefully). To solve this the compiler's been updated to prefer crates from the sysroot to leave Cargo's structure to itself. We'll see if this actually allows the PR to land...
diff --git a/src/librustc_metadata/locator.rs b/src/librustc_metadata/locator.rs
@@ -639,6 +639,34 @@ impl<'a> Context<'a> {
                                                          lib.display()));
                 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((ref prev, _)) = ret {
+                let sysroot = self.sess.sysroot();
+                let sysroot = sysroot.canonicalize()
+                                     .unwrap_or(sysroot.to_path_buf());
+                if prev.starts_with(&sysroot) {
+                    continue
+                }
+            }
             *slot = Some((hash, metadata));
             ret = Some((lib, kind));
         }
