| Age | Commit message (Collapse) | Author | Lines |
|
This bumps the version of the bbl bootloader not to perform 64-bit
accesses to the PLIC. Doing so resulted in the QEMU test machine to fail
to boot:
bbl loader
../machine/mtrap.c:21: machine mode: unhandlable trap 7 @ 0x0000000080001f6e
Power off
Signed-off-by: Tom Eccles <tom.eccles@codethink.co.uk>
|
|
|
|
Stop running macOS builds on Azure Pipelines
The Infrastructure Team agreed to migrate macOS builds to GitHub Actions, so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket.
We can't still fully remove the Azure Pipelines configuration, as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged.
r? @Mark-Simulacrum
|
|
|
|
See GitHub's blog post on why the change was necessary:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
|
|
|
|
Ensure that all LLVM components requested by tests are available on CI
Addresses https://github.com/rust-lang/rust/pull/75064#issuecomment-667722652
I used an environment variable because passing a command line option all the way from CI to compiletest would be just too much hassle for this task.
I added a new variable, but any of the already existing ones defined by CI could be used instead.
r? @Mark-Simulacrum
|
|
Use YAML anchors for try builds
r? `@pietroalbini`
|
|
Trying to fix a problem in CI. Maybe some version of Docker is not
passing '' args correctly?
|
|
|
|
|
|
|
|
This allows us to make use of a YAML anchor when specifying the try
builder config.
|
|
cross-compilation on an x86_64 host.
This promotes aarch64-pc-windows-msvc from a Tier 2 Compilation Target (std) to a Tier 2 Development Platform (std+rustc+cargo+tools).
Fixes #72881
|
|
Previously we would have some platforms where LLVM was linked to rustc
statically, but to the LLVM tools dynamically. That meant we were distributing
two copies of LLVM: one as a separate dylib and one statically linked in to
librustc_driver.
|
|
|
|
|
|
Add aarch64-unknown-linux-musl host builds
This adds aarch64-unknown-linux-musl to the hosts list and adds the build to the dist-arm-linux builder as `@Mark-Simulacrum` suggested to me in Zulip. `@jyn514` requested to be mentioned :smile:
I had to update the config for crosstool-ng as it had a prompt about the glibc version.
I ran `src/ci/docker/run.sh dist-arm-linux` to test it.
```
Build completed successfully in 1:31:50
Compile requests 8180
Compile requests executed 8135
Cache hits 287
Cache misses 7848
Cache timeouts 0
Cache read errors 0
Forced recaches 0
Cache write errors 0
Compilation failures 0
Cache errors 0
Non-cacheable compilations 0
Non-cacheable calls 36
Non-compilation calls 9
Unsupported compiler calls 0
Average cache write 0.000 s
Average cache read miss 6.389 s
Average cache read hit 0.000 s
Cache location Local disk: "/sccache"
Cache size 202 MiB
Max cache size 10 GiB
== clock drift check ==
local time: Sun Sep 6 19:30:17 UTC 2020
network time: Sun, 06 Sep 2020 19:30:17 GMT
== end clock drift check ==
```
Only errors were in miri due to struct fields being private (already been reported [here](https://github.com/rust-lang/rust/issues/76337))
Edit: Maybe it is helpful if I add that it is a working compiler
```sh
/rust-nightly-aarch64-unknown-linux-musl # ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'clippy-preview'
install: installing component 'rustfmt-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'rust-analysis-aarch64-unknown-linux-musl'
install: installing component 'rust-std-aarch64-unknown-linux-musl'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
Rust is ready to roll.
/ # cat test.rs
fn main() { println!("hello world"); }
/ # rustc test.rs
/ # ./test
hello world
# file test
test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
```
|
|
remove orphaned files
Should been part of https://github.com/rust-lang/rust/pull/74163
|
|
|
|
Windows doesn't quite support dynamic linking to LLVM yet, but on other
platforms we do. In #76708, it was discovered that we dynamically link to LLVM
from the LLVM tools (e.g., rust-lld), so we need the shared LLVM library to link
against. That means that if we do not have a shared link to LLVM, and want LLVM
tools to work, we'd be shipping two copies of LLVM on all of these platforms:
one in librustc_driver and one in libLLVM.
Also introduce an error into rustbuild if we do end up configured for shared
linking on Windows.
|
|
|
|
Should been part of https://github.com/rust-lang/rust/pull/74163
|
|
|
|
While waiting for a PR job to start testing my code, I noticed the
symlink-build-dir step took 10 minutes to complete, so I investigated
what caused that.
It seems like something changed in the build environment between version
20200901.1 (where the step took 45 seconds) and version 20200908.1
(where the step took 10 minutes). At the time of writing this commit,
the rust-lang organization is on vertsion 20200908.1, while the
rust-lang-ci organization is at version 20200901.1 (and is not affected
by this yet).
There is no need for this step anymore on GHA, as our XL builders got an
increase in the root paritition size, so this commit removes the code
that moved stuff around on GHA (while keeping it on Azure).
For the record, at the time of writing this, the disk situation is:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 667G 60G 607G 9% /
/dev/sdb1 110G 4.1G 101G 4% /mnt
|
|
|
|
|
|
Set ninja=true by default
Ninja substantially improves LLVM build time. On a 96-way system, using
Make took 248s, and using Ninja took 161s, a 35% improvement.
We already require a variety of tools to build Rust. If someone wants to
build without Ninja (for instance, to minimize the set of packages
required to bootstrap a new target), they can easily set `ninja=false`
in `config.toml`. Our defaults should help people build Rust (and LLVM)
faster, to speed up development.
|
|
Build dist-x86_64-musl with --enable-profiler.
Trying to build a Rust project with `-Zprofile` for target
x86_64-unknown-linux-musl using rustc 1.46.0-nightly (346aec9b0
2020-07-11), installed with rustup, results in the following error.
```
export RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Copt-level=0 -Clink-dead-code -Coverflow-checks=off -Zpanic_abort_tests -Cpanic=abort"export CARGO_INCREMENTAL=0$ cargo build --target=x86_64-unknown-linux-muslCompiling hello_world v0.1.0 (…)error[E0463]: can't find crate for `profiler_builtins`
|
= note: the compiler may have been built without the profiler runtime
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.error: could not compile `hello_world`.
To learn more, run the command again with --verbose.
```
`-Zprofile` is required here to enable grcov profiling.
This is similar in nature to issue
https://github.com/rust-lang/rust/issues/57257, which has been fixed in
asimilar way at https://github.com/rust-lang/rust/pull/60476 .
A fix for Android has also landed not long ago:
https://github.com/rust-lang/rust/pull/70054 .
Signed-off-by: Tiago Lam <tiagol@hadean.com>
|
|
Trying to build a Rust project with `-Zprofile` for target
x86_64-unknown-linux-musl using rustc 1.46.0-nightly (346aec9b0
2020-07-11), installed with rustup, results in the following error.
```
export RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Copt-level=0 -Clink-dead-code -Coverflow-checks=off -Zpanic_abort_tests -Cpanic=abort"export CARGO_INCREMENTAL=0$ cargo build --target=x86_64-unknown-linux-muslCompiling hello_world v0.1.0 (…)error[E0463]: can't find crate for `profiler_builtins`
|
= note: the compiler may have been built without the profiler runtime
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.error: could not compile `hello_world`.
To learn more, run the command again with --verbose.
```
`-Zprofile` is required here to enable grcov profiling.
This is similar in nature to issue
https://github.com/rust-lang/rust/issues/57257, which has been fixed in
asimilar way at https://github.com/rust-lang/rust/pull/60476 .
A fix for Android has also landed not long ago:
https://github.com/rust-lang/rust/pull/70054 .
Signed-off-by: Tiago Lam <tiagol@hadean.com>
|
|
|
|
|
|
|
|
Windows CI builds already install ninja. Install it in all the
Docker-based builds as well.
|
|
Should be re-enabled when we have a recipe for installing ninja on
macOS.
|
|
|
|
|
|
|
|
Flatten the INC definition to one line.
Co-authored-by: lzutao <taolzu@gmail.com>
|
|
This was breaking `#include_next <limits.h>`, such that we weren't
getting definitions of `PATH_MAX` and `_POSIX_ARG_MAX`.
|
|
r=pietroalbini
Remove the full-bootstrap builder from CI
Fixes #75198
|
|
This Emscripten version was the first to be cut after the LLVM 11
release branch was created, so it should be the most compatible with
LLVM 11. The old version we were using was incompatible with LLVM 11
because its wasm-ld did not understand all the relocations that LLVM
11 emits.
|
|
|
|
Move CloudABI to tier 3.
The CloudABI target hasn't had much work done on it in a while, and it doesn't appear to be in active use. It has a fairly substantial amount of code, particularly in the [sys module](https://github.com/rust-lang/rust/tree/5addb135edc2653b07670482a430aac9b655a86b/library/std/src/sys/cloudabi) that requires actively supporting. I contacted @EdSchouten who indicated that many of the CloudABI concepts are now in WASI, and that they are OK with the target being moved to tier 3.
|
|
|
|
Release Notes:
```
v1.38.47: 10/02/2019
--------------------
- Add support for FETCH API in WASM backend. This doesn't support FETCH in the
main thread (`USE_FETCH_WORKER=0` is enforced). #9490
- Redefine errno values to be consistent with wasi. This will let us avoid
needing to convert the values back and forth as we use more wasi APIs.
This is an ABI change, which should not be noticeable from user code
unless you use errno defines (like EAGAIN) *and* keep around binaries
compiled with an older version that you link against. In that case, you
should rebuild them. See #9545.
- Removed build option `-s ONLY_MY_CODE` as we now have much better solutions
for that, like building to a wasm object file or using `STANDALONE_WASM`
etc. (see
https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone).
- Emscripten now supports the config file (.emscripten) being placed in the
emscripten directory rather that the current user's home directory.
See #9543
```
|
|
Add sanitizer support on FreeBSD
Restarting #47337. Everything is better now, no more weird llvm problems, well not everything:
Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.
Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…
```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```
…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:
```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
fn st_flags(&self) -> u32;
#[stable(feature = "metadata_ext2", since = "1.8.0")]
fn st_gen(&self) -> u32;
- #[stable(feature = "metadata_ext2", since = "1.8.0")]
- fn st_lspare(&self) -> u32;
}
#[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
fn st_flags(&self) -> u32 {
self.as_inner().as_inner().st_flags as u32
}
- fn st_lspare(&self) -> u32 {
- self.as_inner().as_inner().st_lspare as u32
- }
}
```
I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
|
|
|
|
Run standard library unit tests without optimizations in `nopt` CI jobs
This was discussed in #73288 as a way to catch similar issues in the future. This builds an unoptimized standard library with the bootstrap compiler and runs the unit tests. This takes about 2 minutes on my laptop.
I confirmed that this method works locally, although there may be a better way of implementing it. It would be better to use the stage 2 compiler instead of the bootstrap one.
Notably, there are currently four `libstd` unit tests that fail in debug mode on `i686-unkown-linux-gnu` (a tier one target):
```
failures:
f32::tests::test_float_bits_conv
f32::tests::test_total_cmp
f64::tests::test_float_bits_conv
f64::tests::test_total_cmp
```
These are the tests that prompted #73288 as well as the ones added in #72568, which is currently broken due to #73328.
|
|
We already have builders which built standard library *test*s without
optimizations, but we previously did not have builders which built the standard
library itself without optimizations and then tested that.
This adds those builds for i686 and x86_64 linux.
|