Since LLVM reversed the order of the debug info graphs, we need to have
a compile unit that exists *before* any functions (`DISubprogram`s) are
created. This allows the LLVM debug info builder to automatically link
the functions to the compile unit.

LLVM pass manager infrastructure is currently getting rewritten to be
more flexible, but the rewrite isn't complete yet.

This makes sure to still use the old way for older LLVM versions.

The new NewArchiveMember is simpler and requires less context,
according to upstream.

This was changed in http://reviews.llvm.org/D21721

Changed in
rust-lang/llvm@0b21d88

…nit level

This was deleted here[1] which appears to be replaced by this[2]
which is a new setPIELevel function on the LLVM module itself.

[1]: http://reviews.llvm.org/D19753
[2]: http://reviews.llvm.org/D19671

Previously, we had a PositionIndependentExecutable, now we simply
choose the highest level. This should be equivalent.

:cake:

This was changed back in
rust-lang/llvm@aacf2fbf

Previously the C type LLVMRelocMode (available as RelocMode in Rust)
was passed as is to the function.
However createTargetMachine expects a Reloc::Model, which is an enum
just one value short.
Additionally, the function was marked as requiring Reloc::Model in the
C code, but RelocMode on the Rust-side.

We now use the correct C type LLVMRelocMode and convert it to an
Optional<Reloc::Model> as expected by the createTargetMachine call the
same the original LLVMCreateTargetMachine function does.
See
https://github.com/llvm-mirror/llvm/blob/c9b262bfbd5b9fb6f10749dba1465569f39bd625/lib/Target/TargetMachineC.cpp#L104-L121

This was found by @eddyb.

The passed error needs to be checked.
Otherwise it will force an abort when it is deconstructed, but a
success value.

Also relax the assertion whenever we have a custom LLVM root as LLVM may
disagree about exact specifics.

We don't actually officially support this at all, and the execution engine
support in LLVM we've had to gut as it's not compiling on MinGW, so just delete
this test for now.

The 3.9 release of LLVM isn't out yet, but this moves us onto that branch to
start tracking it.

Now it prints full paths on MSVC, but we're only interested in path names

…passing 0

Apparently MSVC now has namespaces in backtraces!

@tmiasko did some digging and discovered that
https://reviews.llvm.org/D22858 may be relevant.