about summary refs log tree commit diff
path: root/src/ci/docker
AgeCommit message (Collapse)AuthorLines
2018-03-16ci: Run fewer tests on asmjsAlex Crichton-1/+6
Many tests run on the asmjs builder like compile-fail, ui, parse-fail, etc, aren't actually specific to asm.js. Instead of running redundant test suites this commit changes things up to only run tests that actually emit JS we then pass to node.
2018-03-16ci: Disable optimized tests for asm.jsAlex Crichton-1/+1
Since all tests are compiled with LTO effectively in Emscripten this commit disables optimizations to hopefully squeeze some more time out of the CI builders. Closes #48826
2018-03-03rust: Import LLD for linking wasm objectsAlex Crichton-7/+6
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-04Auto merge of #48600 - Mark-Simulacrum:rustbuild-updates-2, r=alexcrichtonbors-52/+27
Remove --host and --target arguments to configure in Dockerfiles These arguments are passed to the relevant x.py invocation in all cases anyway. As such, there is no need to separately configure them. x.py will ignore the configuration when they are passed on the command line anyway. r? @alexcrichton
2018-03-02Remove --host and --target arguments to configureMark Simulacrum-52/+27
These arguments are passed to the relevant x.py invocation in all cases anyway. As such, there is no need to separately configure them. x.py will ignore the configuration when they are passed on the command line anyway.
2018-02-24Run the external doc tests in tools job.kennytm-12/+27
2018-02-23Disallow toolstate regression at the last week of the 6-week cycle.kennytm-0/+49
2018-02-11Rollup merge of #48120 - matthiaskrgr:typos_src_1, r=alexcrichtonkennytm-1/+1
fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}} via codespell
2018-02-10fix typos in src/{bootstrap,ci,etc,lib{backtrace,core,fmt_macros}}Matthias Krüger-1/+1
2018-02-10Rollup merge of #48098 - alexcrichton:fix-i686-dist-bootstrap, r=Mark-Simulacrumkennytm-1/+2
ci: Actually bootstrap on i686 dist Right now the `--build` option was accidentally omitted, so we're bootstraping from `x86_64` to `i686`. In addition to being slower (more compiles) that's not actually bootstrapping!
2018-02-09rustc: Upgrade to LLVM 6Alex Crichton-1/+1
The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3
2018-02-09ci: Actually bootstrap on i686 distAlex Crichton-1/+2
Right now the `--build` option was accidentally omitted, so we're bootstraping from `x86_64` to `i686`. In addition to being slower (more compiles) that's not actually bootstrapping!
2018-02-05Update clippy and miri submoduleOliver Schneider-1/+1
2018-01-28rustc: Split Emscripten to a separate codegen backendAlex Crichton-4/+7
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-28Auto merge of #47663 - malbarbo:mips-crt-static, r=alexcrichtonbors-46/+28
Do not assume dynamic linking for musl/mips[el] targets All musl targets except mips[el] assume static linking by default. This can be [confusing](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084). When the musl/mips[el] targets was [added](https://github.com/rust-lang/rust/pull/31298), dynamic linking was chosen because of binary size concerns, and probably also because libunwind [didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8) supported mips. Now that we have `crt-static` target-feature (the user can choose dynamic link for musl targets), and libunwind [6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add support to mips, we do not need to assume dynamic linking.
2018-01-27Remove musl/libunwind patch for i686Marco A L Barbosa-31/+0
The i686 problem was fixed upstream: https://github.com/llvm-mirror/libunwind/commit/aa805e415f19f50ebc6f5e1e1e4bf9bb7f61816b
2018-01-25Revert update of the i686-freebsd builderAlex Crichton-1/+1
Looks like llvm 4.0.0 isn't read for that either.
2018-01-25Rollup merge of #47710 - alexcrichton:llvm-6-compat, r=nikomatsakisAlex Crichton-2/+2
First round of LLVM 6.0.0 compatibility This includes a number of commits for the first round of upgrading to LLVM 6. There are still [lingering bugs](https://github.com/rust-lang/rust/issues/47683) but I believe all of this will nonetheless be necessary!
2018-01-24llvm6: Update FreeBSD images to Ubuntu 18.04Alex Crichton-2/+2
Looks like the clang with 16.04 fails to compile LLVM 6, but it looks like clang in 18.04 can indeed compile LLVM 6.
2018-01-24Remove workarounds for cc 1.0.3.Ed Schouten-13/+0
Now that the Rust codebase depends on cc 1.0.4, there is no longer any need to specify a compiler for CloudABI manually. Cargo will automatically call into the right compiler executable.
2018-01-23Build musl with -fPIC for all targetsMarco A L Barbosa-4/+5
2018-01-23Use libuwind 6.0 for all musl targetsMarco A L Barbosa-9/+1
2018-01-22Do not assume dynamic linking for musl/mips[el] targetsMarco A L Barbosa-11/+31
All musl targets except mips[el] assume static linking by default. This can be confusing https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084 When the musl/mips[el] targets was [added](https://github.com/rust-lang/rust/pull/31298), dynamic linking was chosen because of binary size concerns, and probably also because libunwind [didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8) supported mips. Now that we have `crt-static` target-feature (the user can choose dynamic link for musl targets), and libunwind [6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add support to mips, we do not need to assume dynamic linking.
2018-01-16Only enable CloudABI builds for x86-64 for now.Ed Schouten-12/+0
We'll turn on other architectures if it turns out we have enough capacity.
2018-01-16Integrate dist-cloudabi into dist-various-2.Ed Schouten-51/+40
As discussed in #47427, let's not have a separate container for doing CloudABI builds. It's a lot faster if we integrate it into an existing container, so there's less duplication of what's being built. Upgrade the existing container to Ubuntu 17.10, which is required for CloudABI builds. The version of Clang shipped with 16.04 is not recent enough to support CloudABI properly.
2018-01-16Move dist-cloudabi/ into disabled/.Ed Schouten-0/+0
There is not enough capacity to do automated builds for CloudABI at this time.
2018-01-16Add a Docker container for doing automated builds for CloudABI.Ed Schouten-0/+89
Setting up a cross compilation toolchain for CloudABI is relatively easy. It's just a matter of installing a somewhat recent version of Clang (5.0 preferred) and installing the corresponding ${target}-cxx-runtime package, containing a set of core C/C++ libraries (libc, libc++, libunwind, etc). Eventually it would be nice if we could also run 'x.py test'. That, however still requires some more work. Both libtest and compiletest would need to be adjusted to deal with CloudABI's requirement of having all of an application's dependencies injected. Let's settle for just doing 'x.py dist' for now.
2018-01-13Rollup merge of #47283 - malbarbo:musl-1.1.18, r=alexcrichtonkennytm-1/+1
Update musl to 1.1.18 According to http://www.musl-libc.org/download.html: This release corrects regressions in glob() and armv4t build failure introduced in the previous release, and includes an important bug fix for posix_spawnp in the presence of a large PATH environment variable.
2018-01-11Add i586-unknown-linux-musl targetMarco A L Barbosa-8/+13
2018-01-08Update musl to 1.1.18Marco A L Barbosa-1/+1
According to http://www.musl-libc.org/download.html: This release corrects regressions in glob() and armv4t build failure introduced in the previous release, and includes an important bug fix for posix_spawnp in the presence of a large PATH environment variable.
2018-01-07Auto merge of #47157 - malbarbo:shared-build-musl, r=alexcrichtonbors-272/+144
ci: use a shared script to build musl The dist-x86_64-musl, dist-various-1 and dist-i586-gnu-i686-musl builders had different scripts to build musl. This PR creates an unified script, which makes it easier to add new musl targets and update musl and libunwind (used in the musl targets). The libunwind is update from 3.7 to 3.9 for dist-x86_64-musl and dist-i586-gnu-i686-musl (dist-various-1 already used 3.9 version).
2018-01-04Bump to 1.25.0Alex Crichton-0/+1
* Bump the release version to 1.25 * Bump the bootstrap compiler to the recent beta * Allow using unstable rustdoc features on beta - this fix has been applied to the beta branch but needed to go to the master branch as well.
2018-01-03ci: use musl shared script in dist-i586-gnu-i686-muslMarco A L Barbosa-73/+41
2018-01-03ci: use musl shared script in dist-various-1 (for arm targets)Marco A L Barbosa-171/+66
Update libunwind to 39. This is necessary to build the arm targets
2018-01-03ci: use musl shared script in dist-x86_64-muslMarco A L Barbosa-8/+17
2018-01-01Enable compiler docs testing in x86_64-gnuMalo Jaffré-1/+5
2017-12-30Requires tools to test-pass if the corresponding submodule is updated.kennytm-1/+23
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-27Auto merge of #47016 - malbarbo:dist-armv5te, r=alexcrichtonbors-1/+6
Add dist builder for armv5te-unknown-linux-gnueabi (again) The dist builder was first add in https://github.com/rust-lang/rust/pull/46498 and later remove in https://github.com/rust-lang/rust/pull/46498 because of https://github.com/rust-lang/rust/issues/46822. https://github.com/rust-lang/rust/issues/46822 seems to be fixed now (I and @green-s have [tested](https://github.com/rust-lang/rust/pull/46498#issuecomment-353901216) it).
2017-12-26Auto merge of #46554 - ↵bors-11/+113
kennytm:45861-step-4-5-6-7-upload-test-result-and-remove-toolstate-toml, r=alexcrichton [auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation This PR consists of 3 commits. 1. (Steps 4–6) The `toolstate.json` output previously collected is now pushed to the https://github.com/rust-lang-nursery/rust-toolstate repository. 2. (Step 7) Revert commit ab018c7, thus removing all traces of `BuildExpectation` and `toolstate.toml`. 3. (Step 8) Adjust CONTRIBUTION.md for the new procedure. These are the last steps of #45861. After this PR, the toolstate will be automatically computed and published to https://rust-lang-nursery.github.io/rust-toolstate/. There is no need to manage toolstate.toml again. Closes #45861.
2017-12-27Clarify toolstate names. Move publish.py to a more convenient location.kennytm-106/+1
2017-12-27Upload the toolstate to the remote repository.kennytm-9/+213
2017-12-26Add dist builder for armv5te-unknown-linux-gnueabiMarco A L Barbosa-1/+6
2017-12-26Fixup some previous configuration errors.kennytm-2/+5
2017-12-22Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433.Jed Davis-234/+113
The main goal here is to use FreeBSD's normal libc++, instead of statically linking the libstdc++ packaged with GCC, because that libstdc++ has bugs that cause rustc to deadlock inside LLVM. But the easiest way to use libc++ is to switch the build from GCC to Clang, and the Clang package in the Ubuntu image already knows how to cross-compile (given a sysroot and preferably cross-binutils), so the toolchain script now uses that instead of building a custom compiler. This also de-duplicates the `build-toolchain.sh` script.
2017-12-14Download the crosstool from GitHub instead of crosstool-ng.orgkennytm-4/+5
Temporary workaround since crosstool-ng.org was down. Consider mirroring the release tarball as a more permanent solution.
2017-12-11Remove armv5te target from dist-various-1Marco A L Barbosa-6/+1
Reverts https://github.com/rust-lang/rust/pull/46498 I must have made some mistake when I tested that commit and thought armv5te target worked. but testing it now the produced binaries segfaults (https://github.com/rust-lang/rust/pull/46498#issuecomment-350599233). I tried using crosstool-ng and buildroot toolchain (for armv5te) but the produced binaries also segfaults. Maybe there is a issue with the target, but I cannot investigate it any further. I think the best for now is not to distribute the armv5te target. I'm sorry for what happened.
2017-12-05Add armv5te-unknown-linux-gnueabi to cross builderMarco A L Barbosa-1/+6
2017-12-04Rename cross(2) builder to dist-various-{1,2}Marco A L Barbosa-7/+7
Follows the convention of the other builders.
2017-12-03Update the tools CI to use --no-fail-fast and --save-toolstates.kennytm-6/+43
2017-12-03Move the swap the tools test and cargotest within check-aux.kennytm-7/+11
The cargotest job is renamed to tools for clarification.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 12:32:09 +0000