Remove RUSTC_RETRY_LINKER_ON_SEGFAULT hack
It looks like this was added in rust-lang/rust#40422 6 years ago because of issues with the MacOS linker. MacOS got a new linker in the meantime, so that should probably be resolved now. Hopefully.
r? petrochenkov
It looks like this was added 6 years ago because of issues with the
MacOS linker. MacOS got a new linker in the meantime, so that should
probably be resolved now. Hopefully.
CI: Add cargo tests to aarch64-apple-darwin
This adds running of cargo's tests to the aarch64-apple-darwin job. The reason for this is that tier-1 targets are ostensibly supposed to run tests for host tools, but we are not doing that here. We do have fairly good coverage in Cargo's CI, but we don't cover the beta or stable branches here. I think it would be good to have a fallback here.
I think this should only add about 7 minutes of CI time, but I have not measured it. The current job is about 1.5 hours.
In summary of the tier-1 targets:
| Target | rust-lang/cargo | rust-lang/rust |
|--------|-----------------|----------------|
| aarch64-apple-darwin | stable/nightly | ❌ (this PR) |
| aarch64-unknown-linux-gnu | stable/nightly | ✓ |
| x86_64-apple-darwin | nightly | ❌ |
| x86_64-pc-windows-gnu | nightly | ❌ |
| x86_64-pc-windows-msvc | stable | ✓ |
| x86_64-unknown-linux-gnu | stable/beta/nightly | ✓ |
| i686-pc-windows-msvc | ❌ | ❌ |
| i686-unknown-linux-gnu | ❌ | ❌ |
try-job: aarch64-apple
This adds running of cargo's tests to the aarch64-apple-darwin job. The
reason for this is that tier-1 targets are ostensibly supposed to run
tests for host tools, but we are not doing that here. We do have fairly
good coverage in Cargo's CI, but we don't have much coverage of beta or
stable. I think it would be good to have a fallback here.
At the moment, it seems like Windows Server 2025 20250504.1.0 is
misconfigured causing insufficient disk space failures. Temporarily go
back to Windows Server 2022 in the hope that those are not also
misconfigured.
make it possible to use stage0 libtest on compiletest
With https://github.com/rust-lang/rust/pull/119899, building the library tree will require a stage 1 compiler. This is because `compiletest` is defined as a `ToolStd` (since https://github.com/rust-lang/rust/pull/68019) in order to use the in-tree library. As a result, https://github.com/rust-lang/rust/pull/119899 makes certain development workflows more difficult as changes on the compiler tree will now require recompiling `compiletest` each time.
This PR allows switching `ToolStd` to `ToolBootstrap` with a simple boolean option in `bootstrap.toml` to allow `compiletest` to use the stage 0 `libtest` instead.
The changes under `src/ci` are clearly intended to make sure that `compiletest` doesn't break during future bootstrap beta bumps.
Temporarily disable Fuchsia test job to unblock queue
See <https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259> for efforts to fix the test job.
This PR temporarily disables the Fuchsia test job to unblock the queue, so that neither the Fuchsia maintainers nor T-infra maintainers should feel pressured to fix the job ASAP.
Please feel free to re-enable once the test job is fixed.
FYI `@erickt` since you or other Fuchsia maintainers will need to revert this change to merge Fuchsia test job fixes in the future.
r? infra-ci
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly
Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job).
This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations).
I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist.
Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR):
- If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible.
- If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case.
In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits.
r? `@marcoieni`
Remove i586-pc-windows-msvc
See [MCP 840](https://github.com/rust-lang/compiler-team/issues/840).
I left a specialized error message that should help users that hit this in the wild (for example, because they use it in their CI).
```
error: Error loading target specification: the `i586-pc-windows-msvc` target has been removed. Use the `i686-pc-windows-msvc` target instead.
Windows 10 (the minimum required OS version) requires a CPU baseline of at least i686 so you can safely switch. Run `rustc --print target-list` for a list of built-in targets
```
``@workingjubilee`` ``@calebzulawski`` fyi portable-simd uses this target in CI, if you wanna remove it already before this happens
