| Age | Commit message (Collapse) | Author | Lines |
|---|
|
CI: implement job skipping in Python matrix calculation
This removes the `step` YAML anchor and the corresponding bash script.
Best reviewed commit-by-commit.
r? ```@pietroalbini```
|
|
Bump Fuchsia versions
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration` CI bot to use the Rust commit 703dc9ce64d9b31a239a7280d9b5f9ddd85ffed6. This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
r? ``@tmandry``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CI: dynamic jobs
This PR modifies our CI workflows to be dynamic. This means that when a GitHub event is generated, we will run a Python script (`calculate-job-matrix.py`), which decides which CI jobs should be generated. These jobs are defined in `src/ci/github-actions/jobs.yml`).
This should provide a few benefits:
- Once the migration to dynamic jobs is complete, we shouldn't need `expand-yaml-anchors` anymore.
- The job table on PRs (and also the left job column on auto/try builds) should be much cleaner and contain only the jobs that are actually relevant/executed.
- It should be much easier to support dynamic try builds, i.e. to run an arbitrary CI job on a try build.
See [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/job.20matrix.20re-ordered.20PR.20list) for more context.
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
enable clippy for bootstrap on CI PRs (in `mingw-check` image)
Let's keep the bootstrap codebase cleaner.
|
|
CI: add script for installing NodeJS and update it to v20
I centralized the installation on a single place to make it simple to update the NodeJS version across the board.
Fixes: https://github.com/rust-lang/rust/issues/123965
r? `@Mark-Simulacrum`
|
|
r=Mark-Simulacrum
Provide prebuilt std for gnullvm targets
Revival of https://github.com/rust-lang/rust/pull/114346 which waiting on MCP that was accepted recently: https://github.com/rust-lang/compiler-team/issues/710#issuecomment-1942014308
|
|
|
|
|
|
|
|
|
|
|
|
Update how WASI toolchains are used in CI and bootstrap
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Improve the experience of running Docker locally
When running locally, the absence of the `GITHUB_STEP_SUMMARY` environment variable will lead to the following error:
```
::endgroup::
./src/ci/docker/run.sh: line 349: : No such file or directory
```
I've also changed the output artifacts directory to `obj/$image_name`, allowing me to easily run all images locally. We always encounter various strange issues when modifying the test cases in the `codegen` directory.
r? Kobzol cc `@saethlin`
|
|
Previously this command was linting compiler and library together.
As we no longer run clippy on the entire tree unless it's explicitly
requested, we need to update this command by adding `library` path.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
CI: add a script for dynamically computing CI job matrix
It would be great if was easier to run specific CI workflows locally, and also to allow us to spawn a specific CI workflow by bors, to enable running arbitrary try builds. See discussion [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20workflows.20refactoring).
This PR is a first step in that direction.
- Moves the definition of CI runners and (for now) PR jobs into a separate `jobs.yml` file.
- Adds a simple Python script that reads the file, decides which jobs should be active for the current CI workflow, and prints them as JSON to their output.
- The PR job then reads this output and generates its job matrix based on it.
By moving the job definitions from `ci.yml` into a separate file, we can handle it programmatically, which should make it easier to both do local execution of CI jobs and also to do arbitrary try builds.
|
|
This commit updates how the WASI targets are configured with their
toolchain. Long ago a `config.toml` option of `wasi-root` was added to
enable building with the WASI files produced by wasi-libc. Additionally
for CI testing and release building the Rust toolchain has been using a
hard-coded commit of wasi-libc which is bundled with the release of the
`wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is
the go-to solution for compiling/linking WASI code and contains the
more-or-less official releases of wasi-libc. This commit migrates CI to
using wasi-sdk releases and additionally updates `bootstrap` to
recognize when this is configured. This means that with `$WASI_SDK_PATH`
configured there's no further configuration necessary to get a working
build. Notably this also works better for the new targets of WASI as
well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the
wasi-sdk release now has libraries for all targets bundled within it.
|
|
|
|
|
|
ci: test cargo on `aarch64-gnu`
Since `aarch64-unknown-linux-gnu` is a tier-1 target, we should also test cargo on it, especially since cargo's own CI doesn't cover this yet. This might have helped us discover #123733 sooner, which is not a cargo problem but was uncovered by a new cargo test (which we'll have to skip for now). Everything else passes in my local run, so at least we'll have a guard against future regressions.
|
|
Co-authored-by: Eric Huss <eric@huss.org>
|
|
Enable building tier2 target riscv32im-unknown-none-elf
riscv32im-unknown-none-elf was promoted to tier2 in
https://github.com/rust-lang/rust/pull/117874
but it has not yet been added to the list of build targets.
By adding riscv32im-unknown-none-elf to the list of build targets, this PR enables end-users to install this target via rustup.
|
|
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration`
CI bot to use the Rust commit 703dc9ce64d9b31a239a7280d9b5f9ddd85ffed6.
This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang
version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
|
|
|
|
|
|
|
|
[rustdoc] [GUI tests] Make theme switching closer to reality
Better to actually perform actions user do rather than only testing the change through local storage.
As for `browser-ui-test` update: I updated `puppeteer` version (to `0.19.4`) and fixed a bug when displaying the file if it came from an `include`.
r? `@notriddle`
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #114788 (impl get_mut_or_init and get_mut_or_try_init for OnceCell and OnceLock)
- #122291 (Stabilize `const_caller_location` and `const_location_fields`)
- #123357 (CI: Redirect stderr to stdout to order GHA logs)
- #123504 (bootstrap: split cargo-miri test into separate Step)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
bootstrap: split cargo-miri test into separate Step
This makes it easier to test just the driver or the cargo-miri integration.
````@rust-lang/miri```` this means to test both you now need to do `./x.py test miri cargo-miri`.
|
|
CI: Redirect stderr to stdout to order GHA logs
This PR modifies the main CI workflow so that its stderr is redirected to stdout. This should make it so that stderr and stdout output is not interleaved in the wrong order in GHA logs (see discussion [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Github.20actions.20logs.20show.20lines.20in.20the.20wrong.20order)).
|
|
Bump dependencies
Follow up for #123252
Unfortunately this file needs to be manually bumped when any dependencies are bumped in the main lockfile
```
Updating autocfg v1.1.0 -> v1.2.0
Updating chrono v0.4.35 -> v0.4.37
Updating clap v4.5.3 -> v4.5.4
Updating clap_derive v4.5.3 -> v4.5.4
Updating handlebars v5.1.0 -> v5.1.2
Updating itoa v1.0.10 -> v1.0.11
Updating memoffset v0.9.0 -> v0.9.1
Updating openssl-sys v0.9.101 -> v0.9.102
Updating pin-project-lite v0.2.13 -> v0.2.14
Updating r-efi v4.3.0 -> v4.4.0
Updating regex-syntax v0.8.2 -> v0.8.3
Updating security-framework v2.9.2 -> v2.10.0
Updating security-framework-sys v2.9.1 -> v2.10.0
Updating serde_json v1.0.114 -> v1.0.115
Updating syn v2.0.55 -> v2.0.57
Updating tokio v1.36.0 -> v1.37.0
```
|
|
|
|
|
|
Support running library tests in Miri
This adds a new bootstrap subcommand `./x.py miri` which can test libraries in Miri. This is in preparation for eventually doing that as part of bors CI, but this PR only adds the infrastructure, and doesn't enable it yet.
`@rust-lang/bootstrap` should this be `x.py test --miri library/core` or `x.py miri library/core`? The flag has the advantage that we don't have to copy all the arguments from `Subcommand::Test`. It has the disadvantage that most test steps just ignore `--miri` and still run tests the regular way. For clippy you went the route of making it a separate subcommand. ~~I went with a flag now as that seemed easier, but I can change this.~~ I made it a new subcommand. Note however that the regular cargo invocation would be `cargo miri test ...`, so `x.py` is still going to be different in that the `test` is omitted. That said, we could also make it `./x.py miri-test` to make that difference smaller -- that's in fact more consistent with the internal name of the command when bootstrap invokes cargo.
`@rust-lang/libs` ~~unfortunately this PR does some unholy things to the `lib.rs` files of our library crates.~~
`@m-ou-se` found a way that entirely avoids library-level hacks, except for some new small `lib.miri.rs` files that hopefully you will never have to touch. There's a new hack in cargo-miri but there it is in good company...
|
|
Default to light theme if JS is enabled but not working
It doesn't [fix] #123399 but it allows to reduce the problem:
* if JS is completely disabled, then `noscript.css` will be applied
* if JS failed for any reason, then the light theme will be applied (because `noscript.css` won't be applied)
r? `@notriddle`
|
|
|
