Fix handling of SCRIPT_ARG in docker images
Instead of making this a build parameter, pass the SCRIPT as an environment variable.
To this purpose, normalize on always referring to a script in `/scripts`.
For i686-gnu-nopt-2 I had to create a separate script, because Docker seems to be really terrible at command line argument parsing, so it's not possible to pass an environment variable that contains whitespace.
Fixes https://github.com/rust-lang/rust/issues/143962.
try-job: `dist-x86_64-linux`
try-job: `i686-gnu-nopt-*`
try-job: `i686-gnu-*`
try-job: `x86_64-gnu-llvm-19-*`
try-job: `x86_64-gnu-llvm-20-*`
ci cleanup: rustdoc-gui-test now installs browser-ui-test
this removes the need for --unsafe-perm in the Dockerfile.
cc ```@GuillaumeGomez``` ```@Kobzol```
Instead of making this a build parameter, pass the SCRIPT as an
environment variable.
To this purpose, normalize on always referring to a script in
`/scripts`.
For i686-gnu-nopt-2 I had to create a separate script, because
Docker seems to be really terrible at command line argument
parsing, so it's not possible to pass an environment variable that
contains whitespace.
Fix fallback for CI_JOB_NAME
If CI_JOB_NAME is not specified, it's supposed to fall back to the image name, which is `$image`, not `$IMAGE`.
Failing to set the correct CI_JOB_NAME causes failures when running `dist-ohos-*` images locally.
If CI_JOB_NAME is not specified, it's supposed to fall back to
the image name, which is `$image`, not `$IMAGE`.
Failing to set the correct CI_JOB_NAME causes failures when running
`dist-ohos-*` images locally.
Add an aarch64-msvc build running on ARM64 Windows
Resurrecting rust-lang/rust#126341
Per <https://github.com/rust-lang/rfcs/pull/3817> we intend to promote `aarch64-pc-windows-msvc` to Tier 1. As part of that work, we are adding a pre-merge CI job to validate that changes do not break this target.
Additionally, for consistency, the `dist-aarch64-msvc` job will also be run on Arm64 Windows runners.
r? ``@Kobzol``
try-job: `*aarch64-msvc*`
Get rid of build-powerpc64le-toolchain.sh
The dist-powerpc64le-linux-musl runner never actually used the toolchain that the script produced, it instead used the one from crosstool-ng.
The dist-powerpc64le-linux-gnu runner did use it, from what I can tell mainly to get a glibc 2.17 version with ppc64le support backported. Since crosstool-ng has the necessary patches, we can just use crosstool-ng to get an appropriate toolchain. While at it, use kernel 3.10 headers since that's the version documented in platform support for this target.
try-job: dist-powerpc64le-linux-gnu
try-job: dist-powerpc64le-linux-musl
The dist-powerpc64le-linux-musl runner never actually used the toolchain
that the script produced, it instead used the one from crosstool-ng.
The dist-powerpc64le-linux-gnu runner did use it, from what I can tell
mainly to get a glibc 2.17 version with ppc64le support backported.
Since crosstool-ng has the necessary patches, we can just use
crosstool-ng to get an appropriate toolchain. While at it, use kernel
3.10 headers since that's the version documented in platform support for
this target.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Rename `mingw-*` CI jobs to `pr-*`
The name `mingw` confuses people because these CI jobs now do much more than just cross-compile to mingw.
This is basically a find/replace. I chose the name `pr-` because it's job is to do general PR checks,
Skip unnecessary components in x64 try builds
We unnecessarily rebuild `wasm-component-ld`, `llvm-bitcode-linker` and Cranelift during the intermediate PGO builds several times times, which is unnecessarily and increases the duration of try builds. This PR also disables some unnecessary dist components.
r? `````@jieyouxu`````
Enforce in bootstrap that build must have stage at least 1
This PR is a step towards https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523586917. It's very hard or me to make self-contained changes to bootstrap at this moment, so this PR kind of does several things:
1) (first two commits) Try to reduce the usage of `Std::new` in bootstrap, and replace it with a `Builder::std` method (similar to `Builder::compiler`). This is mostly to remove executions of the `Std` step for stage 0, which doesn't make a lot of sense; I'd like to ideally have the invariant that when a step is invoked, it actually builds or does something. Eventually, I'd like for everything to go through `Builder::std`. (Note: I'm not totally married to this idea, if you don't like it, we can remove it from this PR. I mostly did it right now to remove stage 0 std steps from snapshot tests, which shouldn't be there, but we can also filter them out in a different way)
2) Make sure that when you pass `x build compiler`, only the `Assemble` root level step will be invoked, and not the `Rustc` step. Before, both were invoked, which actually ran `Rustc` twice, once with all `crates` filled, and once with no crates (but both actually represent the same situation). Since the `Rustc::make_run` step actually requests a compile that is one stage below it, this actually made `build compiler --stage 0` work, which we don't want to have anymore.
3) Enforce a bootstrap-global invariant that all `build` commands are always on stage `>=1`. If you try to `build` anything on stage 0, it will print a warning and exit bootstrap. This follows the intuition from the new staging rules after the stage redesign; artifacts that are "stage 0" come outside of bootstrap, and we can't really build something for which we don't have source (although we can still test it, but that's for another PR).
Now the logic for build should be quite simple. For pretty much everything except for `Std`, you first use the stage0 compiler to build stage 1. Then you can build a stage 2 <something> using the previously built stage 1 (and then you can continue to stage 3 etc.). And that's it. The default build stage for everything is 1 (modulo download-ci-rustc, but that's a separate can of worms).
The snapshot test infra isn't super nice at the moment, as one of next steps I want to create some simple Builder pattern that will allow us to configure the bootstrap invocations in a more "forward-compatible" way (e.g. now it's not possible to modify the config passed to `configure_with_args`).
There are some things not yet fully resolved for build stage 0:
1) Cargo is still a `ModeRustc` tool, even though it doesn't really have to be, it is buildable with the stage0 compiler
2) bootstrap tools (`opt-dist`, `build-manifest` etc.) are still called stage0 tools, and in the bootstrap output it says something like "stage 0 rustc builds stage 0 opt-dist". Which is a bit weird, but functionally there's no difference, it's just a slightly inconsistent output. We still haven't decided if we should make these tools ignore staging altogether (which is IMO the right choice) or if we want to allow building stage 1/2/3/... bootstrap tools.
r? `@jieyouxu`
try-job: x86_64-rust-for-linux
Build rustc with assertions in `dist-alt` jobs
Revival of https://github.com/rust-lang/rust/pull/131077, to check CI times now that we don't do PGO/BOLT anymore on Linux `-alt` builds.
r? `@ghost`
try-job: dist-x86_64-msvc-alt
try-job: dist-x86_64-linux-alt
CI: rfl: move job forward to Linux v6.16-rc1
Another hopefully routine upgrade to Linux v6.16-rc1, just released.
r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
Chris Denton