| Age | Commit message (Collapse) | Author | Lines |
|
|
|
ci: fix docker cache hash collision
#58416 uncovered a bug in our caching for docker images: if the image `foo` pulls files from the image `bar` and a file in `bar` changed, the hash of `foo` will be the same even though it should be different. In that PR's case, `dist-i686-linux` pulls scripts from `dist-x86_64-linux`, and the PR only changed those scripts, causing an hash collision for `dist-i686-linux`.
We have to fix this, since the image will be rebuilt every time bors switches from testing master to testing beta/stable (and when it switches back), making CI way more painful than it currently is.
The approach used by this PR is to just include all the files in `src/ci/docker` in the hash. It's a bit heavy-handed and it will cause a rebuild of all the images every time a single image changes, but it's the best I can think of.
r? @Mark-Simulacrum
cc @alexcrichton @kennytm
|
|
Before this commit the hash used to cache docker images was calculated
from the image's files and the files in the scripts/ directory. This
worked fine when all the files used by an image were in those
directories, but some images pull files from other images, causing hash
collisions in some cases.
This commit changes the hash to include the files of all the docker
images, causing a rebuild of all the images when a single one changes.
That's a bit heavy-handed, but we have no way to track which files an
image pulls in and hash collisions are really painful to deal with.
|
|
[CI] Update GCC in the dist-linux builders
Upstream LLVM is planning to raise their minimum toolchain requirements, so they may start using C++14 features. This new policy has already landed in the form of a "soft" error.
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html
For GCC, they will require at least version 5.1. This PR moves our crosstool-ng builders to their max GCC 5.2, with a few small patches to fix compatibility. The dist-x86_64-linux builder is updated to GCC 5.5 and LLVM/Clang 8.0.0-rc2, which also affects dist-i686-linux sharing the same scripts.
r? @alexcrichton
|
|
Add riscv64{imac,gc}-unknown-none-elf targets
Previous attempt by @fintelia: https://github.com/rust-lang/rust/pull/58012
Related: https://github.com/rust-embedded/wg/issues/218
|
|
This also updates dist-i686-linux, since it borrows the same scripts.
While we're at it, update llvm+clang+lld to llvm-project 8.0.0-rc2.
|
|
|
|
|
|
|
|
The Ubuntu keyserver is more reliable than the MIT PGP server, which is
prone to going down. This commit also explicitly uses port 80 on the
keyserver for reasons outlined in #57844.
|
|
This reverts commit d3d0bf0e9f4d748b95ed143cc636d159bfcb4a6f, reversing
changes made to 40e6a0bd766ca7b1c582b964131400b8c3e89d76.
|
|
This reverts commit 4c243e2c3d8f02cdcd22fe68acf6a0b3edca2078, reversing
changes made to 64f0032a3739b18ae45387744340d9c7ce48b145.
|
|
Add more debugging code to track down appveyor 259 exit code
cc https://github.com/rust-lang/rust/issues/58160
r? @alexcrichton
|
|
|
|
|
|
|
|
NVPTX target specification
This change adds a built-in `nvptx64-nvidia-cuda` GPGPU no-std target specification and a basic PTX assembly smoke tests.
The approach is taken here and the target spec is based on `ptx-linker`, a project started about 1.5 years ago. Key feature: bitcode object files being linked with LTO into the final module on the linker's side.
Prior to this change, the linker used a `ld` linker-flavor, but I think, having the special CLI convention is a more reliable way.
Questions about further progress on reliable CUDA workflow with Rust:
1. Is it possible to create a test suite `codegen-asm` to verify end-to-end integration with LLVM backend?
1. How would it be better to organise no-std `compile-fail` tests: add `#![no_std]` where possible and mark others as `ignore-nvptx` directive, or alternatively, introduce `compile-fail-no-std` test suite?
1. Can we have the `ptx-linker` eventually be integrated as `rls` or `clippy`? Hopefully, this should allow to statically link against LLVM used in Rust and get rid of the [current hacky solution](https://github.com/denzp/rustc-llvm-proxy).
1. Am I missing some methods from `rustc_codegen_ssa::back::linker::Linker` that can be useful for bitcode-only linking?
Currently, there are no major public CUDA projects written in Rust I'm aware of, but I'm expecting to have a built-in target will create a solid foundation for further experiments and awesome crates.
Related to #38789
Fixes #38787
Fixes #38786
|
|
SGX target: clean up dist builder, update libunwind
This incorporates https://github.com/fortanix/llvm-project/pull/4
Fixes https://github.com/fortanix/rust-sgx/issues/65
r? @alexcrichton
|
|
|
|
compiletest: Support opt-in Clang-based run-make tests and use them for testing xLTO.
Some cross-language run-make tests need a Clang compiler that matches the LLVM version of `rustc`. Since such a compiler usually isn't available these tests (marked with the `needs-matching-clang`
directive) are ignored by default.
For some CI jobs we do need these tests to run unconditionally though. In order to support this a `--force-clang-based-tests` flag is added to compiletest. If this flag is specified, `compiletest` will fail if it can't detect an appropriate version of Clang.
@rust-lang/infra The PR doesn't yet enable the tests yet. Do you have any recommendation for which jobs to enable them?
cc #57438
r? @alexcrichton
|
|
|
|
|
|
|
|
Attempt to debug 259 exit code on AppVeyor
Let's try to dig in a bit more and see where this is coming from, it
looks like AppVeyor is also unsure where this is coming from!
|
|
|
|
|
|
|
|
Let's try to dig in a bit more and see where this is coming from, it
looks like AppVeyor is also unsure where this is coming from!
|
|
Use multiple threads by default. Limits tests to one thread. Do some renaming.
r? @michaelwoerister
|
|
Build the standard library for thumbv7neon-unknown-linux-gnueabihf in CI
Using the `dist-armv7-linux` image instead of `dist-various-1` in order to use the ARMv7 toolchain available in `dist-armv7-linux`.
Closes #57030.
|
|
|
|
|
|
Closes #57030.
|
|
|
|
|
|
|
|
|
|
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
|
|
Several changes to libunwind for SGX target
Two fixes:
* #34978 bites again!
* __rust_alloc are actually private symbols. Add new public versions. Also, these ones are `extern "C"`.
Upstream changes (https://github.com/fortanix/llvm-project/pull/2, https://github.com/fortanix/llvm-project/pull/3):
* b7357de Avoid too new relocation types being emitted
* 0feefe5 Use new symbol names to call Rust allocator
Fixes https://github.com/fortanix/rust-sgx/issues/65
|
|
|
|
use port 80 for retrieving GPG key
This works around firewalls blocking port 11371.
See https://unix.stackexchange.com/questions/75892/keyserver-timed-out-when-trying-to-add-a-gpg-public-key.
|
|
|
|
This works around firewalls blocking port 11371.
See https://unix.stackexchange.com/questions/75892/keyserver-timed-out-when-trying-to-add-a-gpg-public-key.
|
|
|
|
This reverts commit 722b4d695964906807b12379577bce5ee3d23e08, reversing
changes made to 956dba47d33fc8b2bdabcd50e5bfed264b570382.
|
|
|
|
VardhanThigle:Vardhan/x86_64-fortanix-unknown-sgx-tier2_support, r=alexcrichton
Upgrade x86_64-fortanix-unknown-sgx platform support to tier 2
## Overview
1. This PR upgrades x86_64-fortanix-unknown-sgx platform support to tier 2 (std only) by setting up build automation for this target.
1. For supporting unwinding, this target needs to link to a port of LLVM's libunwind (more details could be found in #56979), which will be distributed along with the Rust binaries (similar to the extra musl objects)
### Building and copying libunwind:
We have added a new build script (`build-x86_64-fortanix-unknown-sgx-toolchain.sh`) that will run while the container is built. This will build `libunwind.a` from git source.
While the container is built, the persistent volumes where obj/ gets created aren't yet mapped. As a workaround, we copy the built `libunwind.a` to `obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/` after x.py runs.
If any reviewer knows of a better solution, please do tell.
r? @Mark-Simulacrum
|
|
|
|
The version included in Ubuntu 16.04 repositories in the dist-various-1
docker, Arm GCC version 4.9, does not support the new Armv8-M
architecture.
This commit adds the team-gcc-arm-embedded PPA to get through APT a
newer version of Arm GCC.
|
|
This commit adds the Armv8-M Mainline target in the list of targets that
get their dist components built. It also update the build-manifest so
that this target gets also its dist components uploaded.
|