bors [Sun, 1 Jan 2017 09:56:18 +0000 (09:56 +0000)]
Auto merge of #38726 - japaric:sparc64, r=sanxiyn
sparc64-linux support
This is built on top of #38656 and depends on rust-lang/libc#483
Hello world works.
The libc-test test suite passes.
`panic!` doesn't fully work:
```
$ qemu-sparc64-static ./panic
thread 'main' panicked at 'explicit panic', panic.rs:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Illegal instruction (core dumped)
```
Backtraces don't work either, probably related to the previous point:
bors [Sat, 31 Dec 2016 22:08:32 +0000 (22:08 +0000)]
Auto merge of #38708 - alexcrichton:add-distcheck, r=brson
Gate on distcheck on Travis
This commit adds a new entry to the Travis matrix to gate on distcheck, the illustrious test process that has historically taken *8 hours* to complete and also breaks all the time on nightly. By adding it to Travis we should hope to never see nightly breakage (like https://github.com/rust-lang/rust/issues/38690) because of this ever again!
"But wait, surely we can't wait 8 hours for all PRs!" you might be thinking, and you are indeed correct. The distcheck added here is much more optimized for speed than the old buildbot instances for a number of reasons:
* We're not building *two host compilers* beforehand. The current distcheck bot does a cross for i686 Linux and x86_64 Linux before it actually runs distcheck, building 6 compilers and LLVM twice. None of this is done in parallel as well (e.g. `-j1`). Not doing any of this work will be a huge win!
* We're using sccache to compile LLVM, so it should be much faster. Distcheck on the bots didn't cache LLVM well and rebuilt it every time.
All in all, this version of "distcheck" should be exactly like other matrix entries that run tests except that it's a *little* slower to start as it has to create the source tarball then rebuild the build system in the distcheck dir. Overall this should be well under the 2 hours that Android is currently taking anyway.
bors [Sat, 31 Dec 2016 18:54:31 +0000 (18:54 +0000)]
Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support
Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.
Rebased version of #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...
bors [Sat, 31 Dec 2016 12:44:32 +0000 (12:44 +0000)]
Auto merge of #38709 - alexcrichton:check-xsv, r=nikomatsakis
cargotest: Add xsv to tested crates
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!
bors [Sat, 31 Dec 2016 08:21:59 +0000 (08:21 +0000)]
Auto merge of #38667 - alexcrichton:stage0-tools, r=brson
rustbuild: Compile all support tools in stage0
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.
bors [Sat, 31 Dec 2016 04:44:52 +0000 (04:44 +0000)]
Auto merge of #38729 - alexcrichton:android-steps, r=brson
rustbuild: Add more deps on android-copy-libs
The android-copy-libs step is crucial for running tests on the Android target as
it copies necessary scripts and such to the emulator. We must run that before
running any tests there, but we erroneously only did it for compiletest test
suites!
Alex Crichton [Sat, 31 Dec 2016 02:54:05 +0000 (18:54 -0800)]
rustbuild: Add more deps on android-copy-libs
The android-copy-libs step is crucial for running tests on the Android target as
it copies necessary scripts and such to the emulator. We must run that before
running any tests there, but we erroneously only did it for compiletest test
suites!
Since discriminants do not support i128 yet, lets just calculate the boundaries within the 64 bits
that are supported. This also avoids an issue with bootstrapping on 32 bit systems due to #38727.
bors [Sat, 31 Dec 2016 00:50:46 +0000 (00:50 +0000)]
Auto merge of #38601 - schulzch:master, r=brson
Partial fix for #38489.
Fixes script name resolution for windows by invoking `emcc.bat` instead of `emcc`, etc.
Remaining issue:
```
Traceback (most recent call last):
File "C:\Program Files\Emscripten\emscripten\1.35.0\\emcc", line 1309, in <module>
final = shared.Building.llvm_opt(final, link_opts, DEFAULT_FINAL)
File "C:\Program Files\Emscripten\emscripten\1.35.0\tools\shared.py", line 1471, in llvm_opt
assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:
```
Alex Crichton [Fri, 30 Dec 2016 17:56:43 +0000 (09:56 -0800)]
cargotest: Add xsv to tested crates
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!
Alex Crichton [Fri, 30 Dec 2016 17:26:25 +0000 (09:26 -0800)]
travis: Add a distcheck target
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.
Alex Crichton [Fri, 30 Dec 2016 17:29:21 +0000 (09:29 -0800)]
rustbuild: Fix source tarballs and the vendor dir
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.
Alex Crichton [Wed, 28 Dec 2016 23:01:21 +0000 (15:01 -0800)]
rustbuild: Compile all support tools in stage0
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.
est31 [Wed, 7 Dec 2016 15:28:45 +0000 (16:28 +0100)]
libcompiler_builtins: don't codegen dead code call to eh_personality
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.
est31 [Mon, 5 Dec 2016 23:48:54 +0000 (00:48 +0100)]
Try to fix some things
* 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...)
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
Alex Crichton [Fri, 30 Dec 2016 01:26:41 +0000 (17:26 -0800)]
Rollup merge of #38695 - alexcrichton:debug-appveyor, r=brson
appveyor: Attempt to debug flaky test runs
This commit is an attempt to debug #38620 since we're unable to reproduce it
locally. It follows the [advice] of those with AppVeyor to use the `handle.exe`
tool to try to debug what processes have a handle to the file open.
This won't be guaranteed to actually help us, but hopefully it'll diagnose
something at some point?
Alex Crichton [Fri, 30 Dec 2016 01:26:39 +0000 (17:26 -0800)]
Rollup merge of #38676 - rkruppe:llvm-check-success, r=alexcrichton
Check *all* errors in LLVMRustArchiveIterator* API
Incrementing the `Archive::child_iterator` fetches and validates the next child.
This can trigger an error, which we previously checked on the *next* call to `LLVMRustArchiveIteratorNext()`.
This means we ignore the last error if we stop iterating halfway through.
This is harmless (we don't access the child, after all) but LLVM 4.0 calls `abort()` if *any* error goes unchecked, even a success value.
This means that basically any rustc invocation that opens an archive and searches through it would die.
The solution implemented here is to change the order of operations, such that
advancing the iterator and fetching the newly-validated iterator happens in the same `Next()` call.
This keeps the error handling behavior as before but ensures all `Error`s get checked.
Alex Crichton [Fri, 30 Dec 2016 01:26:35 +0000 (17:26 -0800)]
Rollup merge of #38665 - alexcrichton:pretty-only-host, r=brson
rustbuild: Move pretty test suites to host-only
In an ongoing effort to optimize the runtime of the Android cross builder this
commit updates the pretty test suites to run only for host platforms, not for
target platforms as well. This means we'll still keep running all the suites but
we'll only run them for configured hosts, not for configured targets. This
notably means that we won't be running these suites on Android or musl targets,
for example.