Commit Graph

89 Commits

Author SHA1 Message Date
kennytm 91f8e3721c
Revert "appveyor: Use VS2017 for all our images"
This reverts commit 008e5dcbd5.
2018-11-25 00:25:56 +08:00
bors 4632cf2a2e Auto merge of #55935 - alexcrichton:vs2017, r=Mark-Simulacrum
appveyor: Use VS2017 for all our images

This was [recommended by AppVeyor][1] to see if it has any impact on our
build times, hopefully on the beneficial side of things! This shouldn't
affect our binary compatibility for generated compilers like it would
normally do for Linux.

[1]: https://help.appveyor.com/discussions/questions/29832-did-recent-changes-apply-to-possibly-slow-down-builds#comment_46484879
2018-11-23 23:12:11 +00:00
Alex Crichton 008e5dcbd5 appveyor: Use VS2017 for all our images
This was [recommended by AppVeyor][1] to see if it has any impact on our
build times, hopefully on the beneficial side of things! This shouldn't
affect our binary compatibility for generated compilers like it would
normally do for Linux.

[1]: https://help.appveyor.com/discussions/questions/29832-did-recent-changes-apply-to-possibly-slow-down-builds#comment_46484879
2018-11-13 13:42:05 -08:00
Alex Crichton 0d990c7d54 Switch AppVeyor builds to the GCE cloud
[Recommended by AppVeyor][1] this isn't done by default for all builds
due to the high startup overhead (3-4 minutes for a VM), but that's
paltry compared to our overall build times so should be more than
applicable!

[1]: https://help.appveyor.com/discussions/questions/29832-did-recent-changes-apply-to-possibly-slow-down-builds#comment_46494058
2018-11-13 13:38:04 -08:00
bors d0c869c323 Auto merge of #54718 - froydnj:aarch64-ci, r=alexcrichton
add an appveyor config for aarch64-pc-windows-msvc

This is purely a cargo-cult of things to solicit feedback from humans and/or automation failures.  Not sure that the build artifacts would get packaged properly to start providing nightly tarballs for `libstd`, but this is at least a start.

Fixes #53864.
2018-11-02 09:46:11 +00:00
Nathan Froyd ebf6507d13 switch to LLVM 7.0 as the host compiler
This version ought to work better with MSVC 15.9 preview headers.
2018-10-31 07:19:21 -04:00
Nathan Froyd cd1bfdd3d7 add an appveyor config for aarch64-pc-windows-msvc
Fixes #53864.
2018-10-31 07:19:21 -04:00
Alex Crichton 3c25f80f85 ci: Move global credentials to web configuration
This commit moves a number of our encrypted credentials stored in
configuration files in this repository to env vars on the web UI. This
will hopefully make it easier to rotate credentials in the future as
well as quickly change them if the need arises. (quicker than landing a
PR that is).

This also updates the travis deployment process to always use the `aws`
command line tool which we're already installing on Linux and should
enable us to avoid all `dpl` gem issues as well as have greater control
over what's going where.
2018-10-24 05:42:33 -07:00
Christian Poveda 0724ed68bb Add DIST_REQUIRE_ALL_TOOLS to CI scripts 2018-09-28 08:55:18 -05:00
kennytm 2ccf71c3b2
Migrate the toolstate update bot to rust-highfive 2018-05-14 22:34:53 +08:00
kennytm 9d690d40d0 AppVeyor: Dump crash log on failure. 2018-05-12 08:39:05 -06:00
Alex Crichton 7e5b9ac41e ci: Compile LLVM with Clang 6.0.0
Currently on CI we predominately compile LLVM with the default system compiler
which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and
gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang
6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This
looks to generate faster code according to #49879 which translates to a faster
rustc (as LLVM internally is faster)

The major changes here were to the containers that build Linux releases,
basically adding a new step that uses the previous gcc 4.8 compiler to compile
the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been
updated to download precompiled versions of Clang 6 and configure the build to
use them.

Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as
well as an update to `sccache` on Windows which was needed to correctly work
with `clang-cl`. Finally the MinGW compiler is entirely left out here
intentionally as it's currently thought that Clang can't generate C++ code for
MinGW and we need to use gcc, but this should be verified eventually.
2018-05-09 14:45:34 -07:00
kennytm 649f431acf
Give a name to every CI job.
Bots that read the log can simply look for `[CI_JOB_NAME=...]` to find out
the job's name.
2018-04-06 01:09:59 +08:00
Alex Crichton 64f7e11fc3 Update sccache to its master branch
Ideally I'd like to soon enable sccache for rustbuild itself and some of the
stage0 tools, but for that to work we'll need some better Rust support than the
pretty old version we were previously using!
2018-04-02 12:24:50 -07:00
Alex Crichton 796c78a353 appveyor: Move run-pass-fulldeps to extra builders
We've made headway towards splitting the test suite across two appveyor builders
and this moves one more tests suite between builders. The last [failed
build][fail] had its longest running test suite and I've moved that to the
secondary builder.

cc #48844

[fail]: https://ci.appveyor.com/project/rust-lang/rust/build/1.0.6782
2018-03-24 13:46:57 -07:00
Alex Crichton 16cc9ce8a2 Fix an error in the appveyor config 2018-03-07 13:57:17 -08:00
Alex Crichton 7f465abd4f appveyor: Shard more slow MSVC builders
Take two more slow builders and split them in two to get them under 2 hrs
2018-03-07 07:29:44 -08:00
Alex Crichton d69b24805b rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.

Moving to LLD brings with it a number of benefits for wasm code:

* LLD is itself an actual linker, so there's no need to compile all wasm code
  with LTO any more. As a result builds should be *much* speedier as LTO is no
  longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
  This, I believe at least, is intended to be the main supported linker for
  native code and wasm moving forward. Picking up support early on should help
  ensure that we can help LLD identify bugs and otherwise prove that it works
  great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
  and LLD (from what I can tell at least), so it's in general much better to be
  on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
  will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
  means a postprocessor is no longer needed to show off Rust's "small wasm
  binary size".

LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!

LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.

Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.

Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.

[gc]: https://reviews.llvm.org/D42511
2018-03-03 20:21:35 -08:00
Mark Simulacrum 91fbefa594 Split MinGW tests into two builders on AppVeyor
Run-pass and compile-fail tests appear to take the most significant
chunk of time, so split them into their own builder.
2018-02-23 16:19:17 -07:00
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