Support removed LLVM intrinsics by invoking its AutoUpgrade mechanism.
Turns out that LLVM sometimes renames platform intrinsics or replaces them with first-class instructions.
For example, signed minimum became `select (icmp SLT, a, b), a, b` where `a` and `b` are vectors.
This is blocking the Servo rustup ([relevant failure](http://build.servo.org/builders/windows-dev/builds/226/steps/compile/logs/stdio)), as they're using a few such intrinsics.
The fix in this PR is to invoke LLVM's own `AutoUpgrade` mechanism to do the replacements.
Add -mrelax-relocations=no hacks to fix musl build
* this is just a start, dunno if it will work, but I'll just push it out to get feedback (my rust is still building 😢)
* I don't know much about rustbuild, so i just added that flag in there. it's a total hack, don't judge me
* I suspect the places in the musl .mk files are sufficient (but we may also need it present when building std), I'm not sure, needs more testing.
core: fix `cargo build` for targets with "max-atomic-width": 0
This crate was failing to compile due to dead_code/unused_imports
warnings. This commits disables these two lints for these targets.
---
r? @alexcrichton
cc @Amanieu is `cfg(target_has_atomic = "8")` the right `cfg` to use? I think that all targets that support some form of atomics will at a minimum support byte level atomics.
FWIW, the only thing that's left in `sync::atomic` for these targets is `Ordering` and the `fence` function.
I cannot figure out how to write a test for this, but I observed
incorrect edges as a result of not using memoized pattern here
(e.g., LateLintCheck -> SizedConstraint).
rustc_trans: don't lose the cross-crate DefId, MIR trans needs it.
We might have been missing out on some issues because MIR trans was never being used cross-crate.
cc @rust-lang/compiler
When we hash the inputs to a MetaData node, we have to hash them in a
consistent order. We achieve this by sorting the stringfied `DefPath`
entries. Also, micro-optimie by cache more results across the saving
process.
The reads will occur naturally as the HIR/MIR is fetched from the
tracked tables, and this winds up adding reads to the hir of foreign
def-ids somehow.
The biggest problem, actually, is krate numbers being removed entirely,
which can lead to array-index-out-of-bounds errors.
cc #35123 -- not a complete fix, since really we ought to "map" the old
crate numbers to the new ones, not just detect changes.
