This was intended to land in #37149 but I ended up backing it out to land the
rollup (#38697) last night as I was itching to do so. This morning though xsv
has been fixed now (BurntSushi/xsv#53) so we should be able to add it!
This commit adds a new entry to the Travis matrix which performs a "distcheck",
which basically means that we create a tarball, extract that tarball, and then
build/test inside there. This ensures that the tarballs we produce are actually
able to be built/tested!
Along the way this also updates the rustbuild distcheck definition to propagate
the configure args from the top-level invocation.
Closes#38691
The source tarball creation step would attempt to skip a number of files that we
want to ignore ourselves, but once we've hit the vendor directory we don't want
to skip anything so be sure to vendor everything inside that directory.
Closes#38690
This commit changes all tools and such to get compiled in stage0, not in
later stages. The purpose of this commit is to cut down dependencies on later
stages for future modifications to the build system. Notably we're going to be
adding builders that produce a full suite of cross-compiled artifacts for a
particular host, and that shouldn't compile the `x86_64-unknown-linux-gnu`
compiler more than once. Currently dependencies on, for example, the error index
end up compiling the `x86_64-unknown-linux-gnu` compiler more than necessary.
As a result here we move many dependencies on these tools to being produced by a
stage0 compiler, not a stage1+ compiler. None of these tools actually need to be
staged at all, so they'll exhibit consistent behavior across the stages.
There was a linker error on 32 bit platforms with optimisations turned off,
complaining that there was an undefined reference to "rust_eh_personality",
when compiling the rustc_const_math as stage1 artifact.
Apparently the compiler_builtins crate includes a call to "rust_eh_personality".
If compiled for 64 bits, this call doesn't appear, which explains why the linker
error only happens on 32 bit platforms, and optimisations will get it removed
on 32 bit as well.
There were two origins of the call:
1. A for loop where apparently the compiler wasn't sure
whether next() could panic or not, and therefore generated a landing
pad for the worst case. The minimal reproducible example is "for _ in 0..sr { }".
2. A default impl of uabs where the compiler apparently wasn't sure either
whether iabs() could panic or not. Many thanks to nagisa for
contributing the fix.
This commit also puts extern "C" to the intrinsics, as this is generally a
good thing to do.
* shift so that no panics are generated (otherwise results in linker error)
* no_std as insurance to not get into issues with errors like "cannot satisfy dependencies so `rustc_i128` only shows up once" (pure guessing here, but it doesn't hurt...)
The check inside compiler-rt file int_types.h to #define CRT_HAS_128BIT
looks like:
#if (defined(__LP64__) || defined(__wasm__)) && \
!(defined(__mips__) && defined(__clang__))
#define CRT_HAS_128BIT
#endif
Windows uses LLP64 instead of LP64, so it doesn't ship with the C based
intrinsics.
Also, add libcompiler_builtins to the list of crates that may have platform
specific checks (like the ones we just added).
llvm::LLVMConstIntGetZExtValue doesn't accept values with more than 64 bits.
This fixes an LLVM assertion error when compiling libcore with stage1:
src/llvm/include/llvm/ADT/APInt.h:1336:
uint64_t llvm::APInt::getZExtValue() const:
Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed.
Fixes rebase fallout, makes code correct in presence of 128-bit constants.
This commit includes manual merge conflict resolution changes from a rebase by @est31.
