| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
FreeBSD 10 reached its end-of-life in October 2018, and that toolchain
caused issues in the LLVM 11 upgrade (#73526) that are resolved with the
toolchain from FreeBSD 11.
|
|
|
|
The purpose of the auto-fallible job is to run builders that are likely
to fail on CI without gating on them. Having fail-fast enabled there
kinda defeats the purpose, as if one of them fails we can't monitor the
outcome of the other ones.
This was prompted by the aarch64-gnu builder consistently failing due to
a broken test, preventing us from seeing if the macOS spurious failure
is fixed.
|
|
Add fallible AArch64 CI builder
This adds the `aarch64-gnu` CI builder to the `auto-fallible` job, as a first step in the process of actually gating on it.
r? @Mark-Simulacrum
|
|
Update the WASI libc build to LLVM 10.
Among other things, this brings in [the `__main_argc_argv`] patch,
which simplifies the interaction between the compiler and WASI libc's
startup code, which will help work on reactor support.
[the `__main_argc_argv` patch]: https://github.com/llvm/llvm-project/commit/00072c08c75050ae2c835b7bb0e505475dbcd7b9
r? @alexcrichton
|
|
Update the bundled wasi-libc with libstd
This just updates WASI libc, in preparation for WASI reactor support in
a separate change.
r? @alexcrichton
|
|
Among other things, this brings in [the `__main_argc_argv`] patch,
which simplifies the interaction between the compiler and WASI libc's
startup code, which will help work on reactor support.
[the `__main_argc_argv` patch]: https://github.com/llvm/llvm-project/commit/00072c08c75050ae2c835b7bb0e505475dbcd7b9
|
|
This just updates WASI libc, in preparation for WASI reactor support in
a separate change.
|
|
Enable the profiler on FreeBSD
FreeBSD has been doing this in our own package builds for two months
now.
https://svnweb.freebsd.org/ports?view=revision&revision=535771
|
|
Enable docs on dist-x86_64-musl
Add the `rust-docs` component to toolchain `x86_64-unknown-linux-musl`, which allows people using rustup on their musl-based linux distribution to download the rust-docs.
`--disable-docs` is based on the assumption that `x86_64-unknown-linux-musl` is only a cross-compile target.
I have tested that the docs are built. I assume the build-system will automatically detect the docs and create a `rust-docs` component. I will [monitor](https://rust-lang.github.io/rustup-components-history/x86_64-unknown-linux-musl.html) the components and create a follow-up PR, if the docs aren't published.
See also #70619, where we enabled `rust-lld` to enable the wasm-workflow on musl-based linux distributions.
|
|
- Remove useless --stage 2 argument to checktools.sh
- Fix help text for expand-yaml-anchors (it had a typo)
|
|
Add the rust-docs component to toolchain x86_64-unknown-linux-musl, which allows
people using rustup on their musl-based linux distribution to download the
rust-docs.
|
|
- expand yaml anchors
- don't use --stage 2 for dist; that's already the default
|
|
|
|
FreeBSD has been doing this in our own package builds for two months
now.
https://svnweb.freebsd.org/ports?view=revision&revision=535771
|
|
Downgrade glibc to 2.11.1 for ppc, ppc64 and s390x
As discussed in #73782
I've tested these changes on rust 1.43.0 for all the specified archs and used the resulting binaries to bootstrap building rust 1.43.1.
I've also shortly tested these changes on master on ppc64.
|
|
|
|
|
|
|
|
Enable perf try builder
This adds a dedicated branch for perf to use for CI, intended to allow perf to
enqueue builds without needing to use bors. bors is great, but bors requires an
open PR to work, and we want to invoke perf on closed PRs sometimes (in
particular, rollups).
|
|
This adds a dedicated branch for perf to use for CI, intended to allow perf to
enqueue builds without needing to use bors. bors is great, but bors requires an
open PR to work, and we want to invoke perf on closed PRs sometimes (in
particular, rollups).
|
|
|
|
|
|
|
|
ci: Update dist-{i686,x86_64}-linux to Debian 6
This increases the minimum `{i686,x86_64}-unknown-linux-gnu` platform
from RHEL/CentOS 5 (glibc 2.5 and kernel 2.6.18) to a slightly newer
Debian 6 `squeeze` (glibc 2.11 and kernel 2.6.32). While that release is
already EOL, it happens to match the minimum common versions of two
enterprise distros that do still need Rust support -- RHEL 6 (glibc 2.12
and kernel 2.6.32) and SLES 11 SP4 (glibc 2.11 and kernel 3.0).
Closes #62516.
|
|
ci: Set `shell: bash` as a default, remove duplicates
A follow-up to #74406, this commit merely removes the `shell: bash` lines where they were added in favor of setting defaults for *all* "run" steps in the jobs that run the tests.
The changes in #74406 were needed because of an upstream change to the `windows-2019` GitHub Actions image. Previously, the configuration worked fine without specifying `shell: bash`, but for some reason this broke with a new change that was deployed today. The preceding PR was a hotfix to get CI passing, but there was a slightly less duplicative way to specify the default shell for the jobs, which was to set the `defaults.run` option.
This change applies to the `pr`, `try`, `auto`, and `auto-fallible` jobs, which are derived from the YAML-anchor `base-ci-job`. I did not apply these changes to the `master`, `try-success`, `try-failure`, `auto-success`, or `auto-failure` jobs because they have only a few steps.
cc/r? @Mark-Simulacrum
|
