| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Simply to increase the scope of the testing.
Force debuginfo=0 for a handful of tests so that we can have CI prevent
regressing on more tests.
|
|
Split `run-make` into two {`run-make`,`run-make-cargo`} test suites
## Summary
Split `tests/run-make` into two test suites, to make it faster and more convenient for contributors to run run-make tests that do not need in-tree `cargo`.
| New test suites | Explanation |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tests/run-make` | The "fast path" test suite intended for run-make tests that do not need in-tree `cargo`. These tests may not use `cargo`. |
| `tests/run-make-cargo` | The "slow path" test suite that requires checking out `cargo` submodule and building in-tree `cargo`, and thus will have access to in-tree `cargo`. In practice, these constitute a very small portion of the original `run-make` tests. |
This PR carries out [MCP 847: Split run-make test suite into slower-building test suite with suitably-staged cargo and faster-building test suite without cargo](https://github.com/rust-lang/compiler-team/issues/847).
Fixes rust-lang/rust#135573 (for the tests that do not need in-tree `cargo`).
Fixes rust-lang/rust#134109.
## Remarks
- I considered if we want to split by in-tree tools previously. However, as discussed rust-lang/rust#134109, in practice `rustdoc` is not very slow to build, but `cargo` takes a good few minutes. So, the partition boundary was determined to be along in-tree `cargo` availability.
- The `run-make` tests previously that wanted to use `cargo` cannot just use the bootstrap `cargo`, otherwise they would run into situations where bootstrap `cargo` can significantly diverge from in-tree `cargo` (see https://github.com/rust-lang/rust/pull/130642).
---
try-job: aarch64-msvc-1
try-job: test-various
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: dist-various-1
|
|
To catch obvious build failures of the `src/tools/bump-stage0` early,
before we find out it can't even build when we really need it to work.
|
|
For the ones that explicitly picks which test suite to run.
|
|
|
|
Improve dist for gnullvm hosts
LLVM tools cross-compilation has been fixed by rust-lang/rust#145763 and LLVM downloading from CI no longer causes build error, so let's enable them both.
|
|
ci: Begin running ui tests with `rust.debuginfo-level-tests=1`
To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests work with different debuginfo levels. See https://github.com/rust-lang/rust/issues/61117.
When I looked at run time for different CI jobs, **x86_64-gnu-debug** was far from the bottleneck, so it should be fine to make it perform more work.
A handful of tests are failing so we need to force debuginfo=0 on those for now.
We'll start small with debuginfo=1. We'll step up to debuginfo=2 once most (all?) tests can handle debuginfo=1. There are more failures with debuginfo=2 than with debuginfo=1.
|
|
|
|
|
|
It no longer fails with an error locally.
|
|
This issue has been fixed by
<https://github.com/rust-lang/rust/pull/145763>.
|
|
Fix host code appearing in Wasm binaries
This is a direct fix for issue [132802](https://github.com/rust-lang/rust/issues/132802).
Followed the outline as follows:
> * give a hard error in bootstrap when using gcc to compile for wasm
> * change our CI to use clang instead of gcc
> * add a test that compiling a sample program for wasm32-unknown doesn't give any linker warnings
The `test-various` ci job was also changed.
try-job: test-various
try-job: dist-various-1
try-job: dist-various-2
try-job: x86_64-msvc-1
|
|
To reduce risk of regressing on generating debuginfo e.g. in the form of
ICE:s. This will also ensure that future ui tests support different
debuginfo levels.
When I looked at run time for different CI jobs, **x86_64-gnu-debug**
was far from the bottle neck, so it should be fine to make it perform
more work.
|
|
run spellcheck as a tidy extra check in ci
This is probably how it should've been done from the start.
r? ``@Kobzol``
|
|
|
|
|
|
|
|
Consolidate stage directories and group logs in bootstrap
My post-stage-0-redesign bootstrap fixes aren't done yet, but I think that enough steps have been migrated to the new system that it makes sense to actually modify the directories on disk, and what gets printed when bootstrap runs, so that it actually corresponds to the new system. Before, the printed stages didn't always make sense.
This PR:
- Fixes the numbering of `stageN` directories in the build directory. It was not corresponding to the correct stages before; notice that I did not modify `bootstrap/README.md`, as it was essentially describing what happens after this PR (first commit).
- Unifies all steps that output a build group to use the `Builder::msg` method. It's probably not the final stage, and some of the test steps might not be fully accurate yet, because I didn't fix test step numbering yet, but I think that it's a clear improvement from before, and now that everything uses the same method, we can easily make changes across the board, to ensure that it stays unified (second commit).
r? `@jieyouxu`
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
|
|
|
|
|
|
As they were previously.
|
|
|
|
And move `./x test compiletest --stage=1` to `pr-check-2`, where testing
library artifacts already requires building the stage 1 compiler.
|
|
This updates the wasi-sdk used in CI to build release binaries and run
CI with. No major motivation beyond keeping things up-to-date and
following the development of wasi-sdk.
|
|
move uefi test to run-make
Turn the `uefi` test into a more standard `run-make` test, and execute it using the `test-various` CI job like before.
This is just a straightforward translation of the python code, but using `run-make` to supply the target (hence the 3 separate calls in the docker file).
r? ```@jieyouxu```
cc ```@nicholasbishop```
try-job: test-various
|
|
|
|
This check is relatively cheap, and is a quick way to root out breaking
check flow of `bootstrap` itself.
|
|
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of https://github.com/rust-lang/rust/pull/144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang/rust#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
|
|
|
|
|
|
this makes us less vulnerable to MITM and supply chain attacks.
it also means that the CI scripts are no longer responsible for
tracking the versions of these tools.
it should also avoid the situation where local tsc and CI
disagree on the presense of errors due to them being different versions.
|
|
|
|
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-*`
|
|
this removes the need for --unsafe-perm in the Dockerfile.
|
|
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.
|
|
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>
|
|
Update browser-ui-test version to `0.21.1`
One day I'll find time and motivation to use `package.json` instead. :laughing:
r? `@Kobzol`
|
|
|
|
|
|
|
|
|
|
Also fixed a typo in the sanity check for bootstrap, as we are checking for clang-likeness in every wasm target.
|
|
Added sanity check to bootstrap to hard error on wasm builds without
clang, and changed distribution image `dist-various-2` to use clang to
build for official targets.
|
|
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`````
|
|
Update `browser-ui-test` version to `0.20.7`
This new version fixes some bugs and improve error messages.
r? `````@Kobzol`````
|
|
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
|
|
|
|
|
