| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
The GitHub Actions image has this preinstalled for x86_64 but not M1.
|
|
|
|
|
|
|
|
update which targets we test Miri on
I hope this doesn't cost too much time; running only the "pass" tests should be reasonably fast (1-2 minutes on my system).
Fixes https://github.com/rust-lang/rust/issues/117167
|
|
|
|
This avoids needlessly building cg_clif for other targets and makes it
easier for the dist code to determine if it should distribute cg_clif as
component.
|
|
ci: add a runner for vanilla LLVM 17
For CI cost, this can be seen as replacing the llvm-14 runner we dropped in #114148.
Also, I've set `IS_NOT_LATEST_LLVM` in the llvm-16 runner, since that's not the latest anymore.
|
|
|
|
Additionally, this enables
1. building the documentation
2. Setting `rust.lto` to `thin` to match the x86_64 build
|
|
Unlike the other builders, this one doesn't come with it preinstalled.
|
|
Enable new bors try branch to run on CI
Needed to fix [this error](https://github.com/rust-lang/rust/actions/runs/6420044833/job/17431256956). Inspired by https://github.com/rust-lang/rust/pull/99988
Also, removes `try-merge` from the workflow. It shouldn't have been added in https://github.com/rust-lang/rust/pull/116353.
r? `@Mark-Simulacrum`
|
|
|
|
Remove wasm32-unknown-emscripten tests from CI
This builder tested the wasm32-unknown-emscripten target, which is tier 2 (and so not eligible for testing). In the recent beta [promotion](https://github.com/rust-lang/rust/pull/116362#issuecomment-1744960904), we ran into a problem with this target: emscripten doesn't support passing environment variables into the std environment, so we can't enable RUSTC_BOOTSTRAP for libtest in order to pass -Zunstable-options.
We worked around this for the beta/stable branches, but given this problem, and its tier 2 status, just dropping the target's tests entirely seems warranted. Downgrading to tier 3 may also be a good idea, but that is a separate conversation not proposed here.
|
|
This builder tested the wasm32-unknown-emscripten target, which is tier
2 (and so not eligible for testing). In the recent beta promotion, we
ran into a problem with this target: emscripten doesn't support
passing environment variables into the std environment, so we can't
enable RUSTC_BOOTSTRAP for libtest in order to pass -Zunstable-options.
We worked around this for the beta/stable branches, but given this
problem, and its tier 2 status, just dropping the target's tests
entirely seems warranted. Downgrading to tier 3 may also be a good idea,
but that is a separate conversation not proposed here.
|
|
|
|
|
|
Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
|
|
|
|
r=Mark-Simulacrum
ci: actions/checkout@v3 to actions/checkout@v4
- Bump `actions/checkout` from v3 to v4 since v3 uses Node v16 whose support lasts until `11 Sep 2023` [Ref](https://endoflife.date/nodejs)
- https://github.com/actions/checkout/releases/tag/v4.0.0
|
|
|
|
|
|
|
|
CI: use smaller machines in PR runs
mingw-check job-linux-16c -> job-linux-4c
~job-linux-4c 20 min in auto job
~job-linux-16c 13 min in pr job
with current pr regressed to almost 21 min, it's ok.
mingw-check-tidy job-linux-16c -> job-linux-4c small enough, so reduce to minimal
~ job-linux-16c 3 min
with current pr regressed to almost 5 min, it's ok.
x86_64-gnu-tools job-linux-16c this is top job by time in PR, so don't touch it
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 1 hour in pr job (affected by #114613, actual time ~ 30 min)
x86_64-gnu-llvm-15 job-linux-16c don't change too
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 30 min in pr job
Noticed while working on https://github.com/rust-lang/rust/pull/114621, so current time affected by always rebuilded docker images (but pr images always rebuilded before too, so nvm)
|
|
|
|
|
|
aarch64-msvc: remove CI hack for bad Windows SDK version
This removes hack which manually replaced windows sdk version, as it looks like useless now, as CI uses newer version: https://github.com/rust-lang-ci/rust/actions/runs/5596259246/jobs/10233070602#step:24:929
`C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_io.h` (look at version)
related https://github.com/rust-lang/rust/issues/88796
It's nice to have some way to assert bad version, but i don't see anything except checking env https://github.com/rust-lang/cc-rs/pull/646
|
|
|
|
See https://github.com/rust-lang-ci/rust/actions/runs/5596259246/jobs/10233070602#step:24:929 C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt\corecrt_io.h
|
|
|
|
|
|
CI: include workflow name in concurrency group
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
Found by ``@klensy`` [here](https://github.com/rust-lang/rust/pull/113059#discussion_r1247213606).
|
|
CI: merge msvc cargo and tools jobs
The `x86_64-msvc-cargo` and `x86_64-msvc-tools` jobs both run for ~1 hour, but most of that time is actually spent in building LLVM and `rustc`, so I want to try merging them.

|
|
CI: merge x86_64-gnu-llvm-14 and x86_64-gnu-llvm-14-stage1 CI jobs
Another attempt to shorten CI job times. Suggested by `@the8472` [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20usage/near/367172221).
|
|
|
|
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
|
|
Add an exception for try and try-perf branches to enable concurrent try builds and unrolled rollup builds.
|
|
Instead, only cancel them if the builds have the same commit SHA.
|
|
|
|
|
|
|
|
|
|
|
|
CI: merge `mingw` test CI jobs
Same as https://github.com/rust-lang/rust/pull/112633, but for `mingw`. From the logs it looks like the runner spends 40 minutes compiling `rustc`, and then `10`/`20` minutes running tests. It seems wasteful to split that into two jobs.
CI run: https://github.com/rust-lang/rust/actions/runs/5275702134/jobs/9541479343?pr=112645
r? `@jyn514`
|
|
|
|
Publish docs as github artifacts during CI
Discussed here: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Building.20docs.20for.20PR.20CI
The goal is to make docs available for download after CI runs on PRs, for easy review of API changes.
Notes:
- Currently this only captures library documentation (`core`, `alloc`, `std`, `test`, `proc_macro`)
- You can't see artifacts until the entire workflow run has completed https://github.com/actions/upload-artifact/issues/53
- There is currently a generic file name `ci-artifacts`. No way to customize this based on contained files unfortunately https://github.com/actions/upload-artifact/issues/349
You can find the results at the bottom of the CI "summary" page:
<img width="379" alt="image" src="https://github.com/rust-lang/rust/assets/13724985/d3748e59-242c-40f8-9f54-82177b9b481b">
|