Commit graph

70 commits

Author SHA1 Message Date
Alex Crichton
c6daea7c9a rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.

A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.

There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:

* A *second* LLVM submodule was added in this commit. The main LLVM submodule
  will soon start to drift from the Emscripten submodule, but currently they're
  both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
  This is gated behind a `--enable-emscripten` flag to the configure script. By
  default users should neither check out the emscripten submodule nor compile
  it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
  GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
  of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
  platforms, though. All cross-compiled platforms will not be receiving an
  Emscripten backend yet.

This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.

Closes #46819
2018-01-28 18:32:45 -08:00
kennytm
8ed16fe47a
Requires tools to test-pass if the corresponding submodule is updated.
If a PR intends to update a tool but its test has failed, abort the merge
regardless of current channel. This should help the tool maintainers if the
update turns out to be failing due to changes in latest master.
2017-12-30 17:15:40 +08:00
kennytm
519f92f2aa
Upload the toolstate to the remote repository. 2017-12-27 00:00:45 +08:00
kennytm
ec302a2714
Fixup some previous configuration errors. 2017-12-26 02:14:54 +08:00
kennytm
183964505b
Update the tools CI to use --no-fail-fast and --save-toolstates. 2017-12-03 18:36:56 +08:00
kennytm
128199e39c
Move the swap the tools test and cargotest within check-aux.
The cargotest job is renamed to tools for clarification.
2017-12-03 18:36:56 +08:00
Simon Sapin
f4f18586e7 Move cargotest to separate jobs on Travis-CI and AppVeyor 2017-10-23 13:12:12 +02:00
Tim Neumann
80d7e76185 Rollup merge of #44617 - alexcrichton:download-from-us-west-1, r=aidanhs
ci: Upload/download from a new S3 bucket

Moving buckets from us-east-1 to us-west-1 because us-west-1 is where
rust-central-station itself runs and in general is where we have all our other
buckets.
2017-09-17 13:19:11 +02:00
Alex Crichton
5cfee9b854 ci: Upload/download from a new S3 bucket
Moving buckets from us-east-1 to us-west-1 because us-west-1 is where
rust-central-station itself runs and in general is where we have all our other
buckets.
2017-09-16 08:35:47 -07:00
Alex Crichton
ddd321df91 travis: Move sccache to the us-west-1 region
Most of the other rust-lang buckets are in us-west-1 and I think the original
bucket was just accidentally created in the us-east-1 region. Let's consolidate
by moving it to the same location as the rest of our buckets.
2017-09-14 13:17:25 -07:00
Alex Crichton
8fbed5bc42 Rotate Travis/AppVeyor S3 keys
Haven't done this in awhile so seems like a good idea!
2017-09-09 11:14:43 -07:00
Alex Crichton
4d7dfc1407 appveyor: Use InnoSetup from our mirror
Chocolatey has been pretty flaky, so let's not rely on it.

Closes #43985
2017-08-22 19:42:28 -07:00
kennytm
438abf0a58
Stop testing i586-pc-windows-msvc on AppVeyor.
Fixes #43881. Reduces AppVeyor test time back to ~2 hours on
average.

The i586 libstd was never tested before Aug 13th, so this PR
brings the situation back to the previous status-quo.
2017-08-15 22:41:38 +08:00
Mark Simulacrum
3fe5721764 Attempt to fix appveyor 2017-07-19 07:01:23 -07:00
Simon Sapin
a148f5ba24 Enable profiler on "alternate" builds
This hopefully fixes #42967 and #43085.
2017-07-11 14:01:04 +02:00
Marco Castelluccio
ce56daf37b Don't enable profiler on MinGW targets, as compiler-rt can't currently be compiled with MinGW 2017-06-07 12:50:50 +01:00
Marco Castelluccio
4c908a9d37 Enable profiler selectively on some builders 2017-06-06 18:09:33 +01:00
Alex Crichton
7644508b4e appveyor: Wrap handle.exe download in a retry
Should help deal with spurious download failures.
2017-05-15 12:01:09 -07:00
Alex Crichton
c30e007b86 Update sccache binaries to mozilla/sccache@d3627d766
This commit updates the sccache binaries to fix a cache load failure seen
on #41926, fixed by mozilla/sccache#119
2017-05-12 09:07:10 -07:00
Alex Crichton
aa891a57a1 ci: Update sccache build
Pulls in mozilla/sccache@ef0d77543 to fix #40240 again after the builds included
in #41447 forgot to include the mio fixed included in #41076.

Closes #40240
2017-04-29 00:29:54 -07:00
Alex Crichton
2e72bcb934 appveyor: Use Ninja/sccache on MSVC
Now that the final bug fixes have been merged into sccache we can start
leveraging sccache on the MSVC builders on AppVeyor instead of relying on the
ad-hoc caching strategy of trigger files and whatnot.
2017-04-27 07:19:34 -07:00
Alex Crichton
499b84aca8 travis: Update sccache build used
This build is no longer a forked version with temporary bugfixes, everything
should be upstreamed!
2017-04-27 07:18:01 -07:00
Alex Crichton
d1db74b63e appveyor: Upgrade to gcc for mingw 6.3.0
This commit sort of brings back #40777 by upgrading back to 6.3.0. While
investigating #40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for #40184 contained in #40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.

I'm going to optimistically say...

Closes #40546
2017-04-26 06:58:50 -07:00
bors
0777c757a6 Auto merge of #40123 - TimNN:llvm40, r=alexcrichton
LLVM 4.0 Upgrade

Since nobody has done this yet, I decided to get things started:

**Todo:**

* [x] push the relevant commits to `rust-lang/llvm` and `rust-lang/compiler-rt`
* [x] cleanup `.gitmodules`
* [x] Verify if there are any other commits from `rust-lang/llvm` which need backporting
* [x] Investigate / fix debuginfo ("`<optimized out>`") failures
* [x] Use correct emscripten version in docker image

---

Closes #37609.

---

**Test results:**

Everything is green 🎉
2017-04-24 22:18:16 +00:00
Tim Neumann
67560f6fae FIN: switch appveryor to mingw with posix threads 2017-04-23 22:00:03 +02:00
Tim Neumann
5bd4e27db2 FIN: update appveyor mingw description 2017-04-23 22:00:02 +02:00
Aidan Hobson Sayers
24640b306e Disable git caches again 2017-04-19 16:29:47 +01:00
Aidan Hobson Sayers
bb843582ca Add a comment for disabling errexit 2017-04-14 15:30:01 +01:00
Corey Farwell
a2c032631b Rollup merge of #41075 - aidanhs:aphs-enable-appveyor-cache, r=alexcrichton
Re-enable appveyor cache

After breaking the queue last time, I'm cautiously back with a PR to re-enable caching on appveyor.

If you look at https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2623/job/46o90by4ari6gege (one of the multiple runs that started failed, there are actually two errors - one for restoring the cache, one right at the bottom for creating a directory. I only noticed the restore error at the time as I was a bit rushed to revert and didn't stop to wonder why it continued - turns out appveyor [does not abort on cache restore failure](https://github.com/appveyor/ci/issues/723).

Turns out the cause of the build failures was the cache directory existing and me being thinking that because mkdir on windows is [recursive by default](http://stackoverflow.com/a/905239/2352259), it ignores the error if the directory already exists. Apparently this is not true, so now it checks if the directory exists before attempting to create.

In addition, I've added some more paranoia to double check everything is sane.
2017-04-07 09:20:07 -04:00
Alex Crichton
e60ea55f66 travis: Update sccache binaries
I've tracked down what I believe is the last spurious sccache failure on #40240
to behavior in mio (carllerche/mio#583), and this commit updates the binaries to
a version which has that fix incorporated.
2017-04-04 15:55:23 -07:00
Aidan Hobson Sayers
b970bc2a79 Enable appveyor cache, add more paranoia 2017-04-04 23:41:38 +01:00
Aidan Hobson Sayers
fe0fbbff5c Disable appveyor cache 2017-03-30 01:33:45 +01:00
Corey Farwell
a9dc8ac7ac Rollup merge of #40780 - aidanhs:aphs-cache-git-modules, r=alexcrichton
Attempt to cache git modules

Partial resolution of #40772, appveyor remains to be done once travis looks like it's working ok.

The approach in this PR is based on the `--reference` flag to `git-clone`/`git-submodule --update` and is a compromise based on the current limitations of the tools we're using.

The ideal would be:
1. have a cached pristine copy of rust-lang/rust master in `$HOME/rustsrc` with all submodules initialised
2. clone the PR branch with `git clone --recurse-submodules --reference $HOME/rustsrc git@github.com:rust-lang/rust.git`

This would (in the nonexistent ideal world) use the pristine copy as an object cache for the top level repo and all submodules, transferring over the network only the changes on the branch. Unfortunately, a) there is no way to manually control the initial clone with travis and b) even if there was, cloned submodules don't use the submodules of the reference as an object cache. So the steps we end up with are:

1. have a cached pristine copy of rust-lang/rust master in `$HOME/rustsrc` with all submodules initialised
2. have a cloned PR branch
3. extract the path of each submodule, and explicitly `git submodule update --init --reference $HOME/rustsrc/$module $module` (i.e. point directly to the location of the pristine submodule repo) for each one

I've also taken some care to make this forward compatible, both for adding and removing submodules.

r? @alexcrichton
2017-03-29 16:53:29 -04:00
Aidan Hobson Sayers
0347ff5823 Attempt to cache git modules 2017-03-29 02:51:56 +01:00
Alex Crichton
e87dd42cfe appveyor: Downgrade MinGW to 6.2.0
It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an
attempted workaround (#40777) does not actually fix (#40835). The original
motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer
builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back
in time and still contains the fix we need.

Closes #40835
2017-03-27 13:07:33 -07:00
Alex Crichton
bff332e0a2 travis: Update sccache again
Looks like the last version was built with mio 0.6.5 which now has known bugs
against it. This build includes mio 0.6.6
2017-03-24 19:00:35 -07:00
bors
8cf8fc9d89 Auto merge of #40777 - alexcrichton:update-mingw-compilers, r=aturon
appveyor: Upgrade MinGW toolchains we use

In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.

When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.

I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.

Closes #40546
2017-03-24 18:40:57 +00:00
Alex Crichton
e6e8c91961 appveyor: Upgrade MinGW toolchains we use
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.

When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.

I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.

Closes #40546
2017-03-24 09:59:18 -07:00
bors
366386c46d Auto merge of #40676 - alexcrichton:update-sccache, r=brson
travis: Update sccache binary

Pick up mozilla/sccache#82
2017-03-24 10:11:05 +00:00
Alex Crichton
05c4051f64 travis: Update sccache binary 2017-03-23 10:16:57 -07:00
Alex Crichton
823715c18e appveyor: Leverage auto-retry to upload to S3
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...

Closes #39074
2017-03-23 07:07:02 -07:00
Alex Crichton
6ae22346b8 appveyor: Use Ninja to build LLVM on MinGW
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.

I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...

Closes #40546
2017-03-21 19:18:56 -07:00
Alex Crichton
7305ca3852 travis: Don't set RUST_LOG globally
I have a suspicion that this caused a large regression in cycle times by forcing
the compiler to perform more checks on every `debug!` statement, so let's test
this out by removing the `RUST_LOG` env var globally.

This regression in cycle time was witnessed between [two] [builds] where the
[PR] in question didn't do much suspicious. Judging by how the stage0 times
*also* regressed though then this is my best guess.

[two]: https://travis-ci.org/rust-lang/rust/builds/210149932
[builds]: https://travis-ci.org/rust-lang/rust/builds/210179995
[PR]: https://github.com/rust-lang/rust/pull/40446
2017-03-20 14:32:36 -07:00
Alex Crichton
ec829fe00e travis: Update sccache binary
I've built a local copy with mozilla/sccache#79 and mozilla/sccache#78. Let's
see if that helps #40240!
2017-03-16 07:55:15 -07:00
Alex Crichton
f27bd73fd2 appveyor: Turn down sccache logging
Let's not have it be quite so verbose
2017-03-13 12:47:37 -07:00
Vadim Petrochenkov
9b8b3b2b03 rustbuild: Add option for enabling partial LLVM rebuilds 2017-03-12 14:02:49 +03:00
Alex Crichton
c60a58b6d1 Attempt to debug sccache in more locations
This should hopefully add support for debugging OSX and Windows presumed sccache
failures instead of just the Linux ones.
2017-03-11 09:07:50 -08:00
Alex Crichton
65b46098b7 appveyor: Use sccache on pc-windows-gnu for caching
Now that mozilla/sccache#43 is fixed the caching works for MinGW on Windows. We
still can't use it for MSVC just yet, but I'll try to revive that branch at some
point.
2017-02-27 11:51:44 -08:00
Alex Crichton
c08f3824cd travis: Make more network requests retryable
This commit attempts to move more network operations to being retryable through
various operations. For example git submodule updates, downloading snapshots,
etc, are now all in retryable steps.

Hopefully this commit can cut down on the number of network failures we've been
seeing!
2017-02-25 21:28:54 -08:00
Alex Crichton
255a87499d Update sccache binaries on CI
Currently CI builds can fail spuriously during the LLVM build (#39003). I
believe this is due to sccache, and I believe that in turn was due to the fact
that the sccache server used to just be a raw mio server. Historically raw mio
servers are quite complicated to get right, but this is why we built Tokio! The
sccache server has been migrated to Tokio which I suspect would fix any latent
issues.

I have no confirmation of this (never been able to reproduce the deadlock
locally), but my hunch is that updating sccache to the master branch will fix
the timeouts during the LLVM build.

The binaries previously came from Gecko's infrastructure, but I've built new
ones by hand for Win/Mac/Linux and uploaded them to our CI bucket.
2017-02-24 13:16:54 -08:00