| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Enable sanitizers and profiler for aarch64-unknown-linux-musl
This is pretty heavily cargo-culted, hopefully I didn't screw it up too badly.
|
|
ci: Add support for dist-loongarch64-linux
We are preparing to promote loongarch64-unknown-linux-gnu to Tier 2, and one of the tasks is to add CI support. We are currently in the process of upgrading the dependencies for the build tools, and before this is completed, we would like to request comments. Thanks
#### Progress
- [x] Update linux-raw-sys to 0.3.2 (rust-lang/cargo#11998)
- [x] Update openssl-src to 111.25.3+1.1.1t (rust-lang/cargo#12005)
- [x] bootstrap: Update linux-raw-sys to 0.3.2 (rust-lang/rust#110516)
- [x] Update linux-raw-sys to 0.3.4 (rust-lang/rust#110518)
- [x] Update cargo (rust-lang/rust#110834)
- [x] linux_like: Add missing constants for loongarch64 (rust-lang/libc#3237)
- [x] Release 0.2.143 (rust-lang/libc#3236)
- [x] Update libc to 0.2.144 (rust-lang/cargo#12098)
- [x] Update cargo (rust-lang/rust#111456)
Tier 2 with host tools MCP: https://github.com/rust-lang/compiler-team/issues/518
|
|
|
|
|
|
support PGO on custom project
make PGO easier for custom toolchain distribution.
r? `@Kobzol`
|
|
|
|
Co-Authored-By: YANG Xiaojuan <yangxiaojuan@loongson.cn>
|
|
|
|
|
|
Remove `tidy` key in PR CI
This avoids confusing error messages when adding an `auto` job to CI (as recommended in the dev-guide: https://rustc-dev-guide.rust-lang.org/tests/ci.html#using-ci-to-test).
cc https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Do.20.60needs-profiler-support.60.20tests.20not.20run.20in.20CI.3F/near/355302998
r? `@ghost`
|
|
Remove aws cli install.
All runner images have the AWS CLI 2 installed, so there isn't a really strong reason to install our own version anymore.
The version we were installing was 1.27.122. The runner images currently have 2.11.x (the exact version varies by image).
I do not have the means to really test if the new version has any issues. I looked at all the `aws` commands, and none of them seem to be doing anything unusual. The page at https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html contains a list of all the breaking changes, and I didn't see anything that looked important.
|
|
Update the version of musl used on `*-linux-musl` targets to 1.2.3
Update the version of musl used on our Linux musl targets from 1.1.24 to 1.2.3 as proposed in rust-lang/compiler-team#572. musl 1.2.3 is the latest version of musl and supports the same range of Linux kernels as the 1.1 series. As such, it does not affect the minimum supported version of Linux for any of the musl targets.
One of the major musl 1.2 features is support for [time64](https://musl.libc.org/time64.html). This support is both source and ABI compatible with programs built against musl 1.1 and so updating the musl version for these targets should not cause Rust programs to fail to run or compile (a [crater run](https://github.com/rust-lang/rust/pull/107129#issuecomment-1407196104) has been completed which demonstrates this for the `i686-unknown-linux-musl` target).
Once this change reaches stable, the `libc` crate will then be able to [update their definitions to support 64-bit time](https://github.com/rust-lang/libc/pull/3068), matching the default musl 1.2 APIs exactly.
Fixes #91178
|
|
This avoids confusing error messages when adding an `auto` job to CI (as
recommended in the dev-guide: https://rustc-dev-guide.rust-lang.org/tests/ci.html#using-ci-to-test).
|
|
Use builtin FFX isolation for Fuchsia test runner
FFX has new builtin support for isolating the daemon's environment. This switches the manual isolation originally written to that new builtin feature.
r? ````@tmandry````
|
|
FFX has new builtin support for isolating the daemon's environment. This
switches the manual isolation originally written to that new builtin
feature.
|
|
ci: upgrade and refactor crosstool-ng builders
The first commit upgrades our builders from crosstool-ng 1.24.0 to 1.25.0. There are otherwise no changes intended to the toolchains we're using, but there are some minor version upgrades as a result, especially GCC 8.3.0 to 8.5.0. The newer crosstool-ng will position us well to make toolchain upgrades in the future though, as we were maxed out before and it now goes up to GCC 11.
The second commit refactors our config management to only commit a "mini-defconfig" for each target, produced by `ct-ng savedefconfig`. This makes it much clearer which settings we're actually changing, and also makes it easier to ensure consistency for things like mirror management.
|
|
Optimize builder sizes
The infra-team is continuously monitoring the efficiency of the CI system in an effort to improve overall build times and resource usage. Some builders have used much less than their allocated resources, so we are testing smaller builder sizes for them.
r? `@pietroalbini`
|
|
|
|
|
|
|
|
|
|
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builders for some of the `x86_64-gnu` targets have used much less
resources than allocated in the past, so we are testing a smaller
builder size for them.
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builder for the `mingw-check` target have used much less resources
than allocated in the past, so we are testing a smaller builder size for
it.
|
|
The infra-team is continuously monitoring the efficiency of the build
system in an effort to improve overall build times and resource usage.
The builders for the `i686-gnu` targets have used much less resources
than allocated in the past, so we are testing a smaller builder size for
them.
|
|
Rollup of 9 pull requests
Successful merges:
- #108416 (black_box doc corrections for clarification - Issue #107957)
- #109379 (Replace `yes` command by `while-echo` in test `tests/ui/process/process-sigpipe.rs`)
- #110266 (Update documentation wording on path 'try_exists' functions)
- #110329 (Improve tests for #110138)
- #110418 (Spelling rustdoc)
- #110587 (Fix `std` compilation error for wasi+atomics)
- #110594 (`rustc --help` add `--cfg` SPEC declaration.)
- #110792 (Use the standard macOS CI runner)
- #110817 (Add regression tests for const-generic inherent associated types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Revert "Download the GCC sources insecurely"
This reverts commit 3da037f82988b8b3aca2ce13c5c81ba975923cab.
This workaround was added after TLS problems with Debian 6 were noted in <https://github.com/rust-lang/rust/pull/86586#issuecomment-868355356>, but we should be well past that since #95026, where our oldest images are now based on CentOS 7.
|
|
|
|
Allow older LLVM versions to have missing components
This check was introduced by #77280 to ensure that all tests that are filtered by LLVM component are actually tested in CI. However this causes issues for new targets (e.g. #101069) where support is only available on the latest LLVM version.
This PR restricts the tests to only CI jobs that use the latest LLVM version.
|
|
This reverts commit 3da037f82988b8b3aca2ce13c5c81ba975923cab.
|
|
Spelling src ci
The various src/* items seem slightly disparate, so I'm doing src/* individually.
split from https://github.com/rust-lang/rust/pull/110392
|
|
* architecture
* configures
* preparation
* toolstate
* unknown
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
Like #107044, this will let us track compatibility with LLVM 16 going
forward, especially after we eventually upgrade our own to the next.
This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with
that change in #106085.
|
|
Reduce core counts for a number of builders
Best reviewed by-commit; first commit renames all builder names to include core counts.
Applied changes for these builders (only on the auto branch, haven't touched PR CI):
- arm-android -> 8 core (currently at 39 minutes; 25.58% CPU)
- armhf-gnu -> 8 core (currently at 31 minutes; 30.97% CPU)
- dist-aarch64-linux -> 8 core (currently at 35 minutes; 55.38% CPU)
- dist-android -> 8 core (currently at 18 minutes; 43.03% CPU)
- dist-armhf-linux -> 8 core (currently at 27 minutes; 54.71% CPU)
- dist-armv7-linux -> 8 core (currently at 29 minutes; 50.33% CPU)
- dist-i586-gnu-i586-i686-musl -> 8 core (currently at 27 minutes; 48.31% CPU)
- dist-i686-linux -> 8 core (currently at 32 minutes; 52.39% CPU)
- dist-mips-linux -> 8 core (currently at 25 minutes; 55.09% CPU)
- dist-mips64-linux -> 8 core (currently at 25 minutes; 55.33% CPU)
- dist-mips64el-linux -> 8 core (currently at 26 minutes; 54.93% CPU)
- dist-mipsel-linux -> 8 core (currently at 25 minutes; 55.38% CPU)
- dist-powerpc-linux -> 8 core (currently at 26 minutes; 55.77% CPU)
- dist-powerpc64-linux -> 8 core (currently at 27 minutes; 55.03% CPU)
- dist-powerpc64le-linux -> 8 core (currently at 27 minutes; 54.95% CPU)
- dist-riscv64-linux -> 8 core (currently at 26 minutes; 54.43% CPU)
- dist-s390x-linux -> 8 core (currently at 30 minutes; 55.97% CPU)
- dist-various-1 -> 8 core (currently at 36 minutes; 29.16% CPU)
- dist-various-2 -> 8 core (currently at 27 minutes; 32.69% CPU)
- dist-x86_64-freebsd -> 8 core (currently at 27 minutes; 51.69% CPU)
- dist-x86_64-illumos -> 8 core (currently at 30 minutes; 54.88% CPU)
- dist-x86_64-musl -> 8 core (currently at 39 minutes; 57.56% CPU)
- dist-x86_64-netbsd -> 8 core (currently at 26 minutes; 55.82% CPU)
- mingw-check -> 8 core (currently at 17 minutes; 35.00% CPU)
- test-various -> 8 core (currently at 22 minutes; 44.84% CPU)
- wasm32 -> 8 core (currently at 19 minutes; 62.94% CPU)
- x86_64-gnu -> 8 core (currently at 32 minutes; 50.31% CPU)
- x86_64-gnu-stable -> 8 core (currently at 32 minutes; 51.23% CPU)
- x86_64-gnu-aux -> 8 core (currently at 22 minutes; 46.39% CPU)
- x86_64-gnu-debug -> 8 core (currently at 21 minutes; 53.93% CPU)
- x86_64-gnu-distcheck -> 8 core (currently at 38 minutes; 55.93% CPU)
- x86_64-gnu-llvm-15 -> 8 core (currently at 34 minutes; 52.99% CPU)
- x86_64-gnu-llvm-14 -> 8 core (currently at 34 minutes; 52.09% CPU)
- x86_64-gnu-llvm-14-stage1 -> 8 core (currently at 33 minutes; 51.13% CPU)
- x86_64-gnu-nopt -> 8 core (currently at 29 minutes; 53.36% CPU)
- x86_64-gnu-tools -> 8 core (currently at 22 minutes; 40.56% CPU)
We may also want to look at merging some of these builders in the future (to deduplicate stage0 builds and such) but that can happen separately - and is more work than just adjusting core counts.
r? `@pietroalbini`
|
|
This check was introduced by #77280 to ensure that all tests that are
filtered by LLVM component are actually tested in CI. However this
causes issues for new targets (e.g. #101069) where support is only
available on the latest LLVM version.
This PR restricts the tests to only CI jobs that use the latest LLVM
version.
|
|
|
|
These builders aren't particularly high on overall average CPU usage and finish in typically around
30 minutes. Cutting their core counts will hopefully not significantly increase wall-time while
cutting costs, allowing us to shift some of the wins into our slower builders.
|
|
This will allow moving jobs between 8 and 16 core VMs in the next commit
more easily.
|
|
|
|
|
|
This is a companion PR to rust-lang/promote-release#58, which moves the
relevant optimal code to rust-lang/promote-release. As mentioned in the
comments of that PR, this is expected to cut CI costs (and time, though
predominantly felt on fast builders) and reduce wasted resources due to
in-practice single-threaded compression not using the full 8+ vCPU
builders we have available.
|
|
Improve PR job names in Github Actions preview
Fixes https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/PR.20CI.20job.20names.
Before: `CI / PR (mingw-check, false, ubuntu-20.04-16core-64gb) (pull_request)`
After: `CI / PR - mingw-check (pull_request)`
r? ``@jyn514``
|
|
Before: `CI / PR (mingw-check, false, ubuntu-20.04-16core-64gb) (pull_request)`
After: `CI / PR - mingw-check (pull_request)`
|
|
|
|
Use `getentropy()` instead of `/dev/urandom` on Emscripten
`/dev/urandom` is usually available on Emscripten, except when using
the special `NODERAWFS` filesystem backend, which replaces all normal
filesystem access with direct Node.js operations.
Since this filesystem backend directly access the filesystem on the
OS, it is not recommended to depend on `/dev/urandom`, especially
when trying to run the Wasm binary on OSes that are not Unix-based.
This can be considered a non-functional change, since Emscripten
implements `/dev/urandom` in the same way as `getentropy()` when not
linking with `-sNODERAWFS`.
|
|
`getentropy()` is available since Emscripten 2.0.5.
See:
https://github.com/emscripten-core/emscripten/pull/12240
|
|
Use llvm 16.0.0 instead of 16.0.0-rc4 for build-clang.sh
Ref: https://github.com/rust-lang/rust/pull/107224
This PR doesn't make any update on LLVM submodule used by Rust repo, but would be super keen to update it, if necessary (https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html). LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1.
- https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html
|