Make parallel frontend CI job compile tests in parallel by zetanumbers · Pull Request #157705 · rust-lang/rust

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

zetanumbers · 2026-06-10T12:56:10Z

It is time to have a CI job to catch parallel frontend issues for tests. This PR sets RUST_TEST_THREADS to 1 to sequentially execute each test to achieve max thread utilization by a single rustc process. Then iteration-count option is set to 2 to repeat each test since parallel frontend issues usually don't reproduce reliably.

try-job: optional-x86_64-gnu-parallel-frontend

rustbot · 2026-06-10T12:56:17Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: infra-ci
infra-ci expanded to Kobzol, Mark-Simulacrum, jdno, jieyouxu, marcoieni
Random selection from Mark-Simulacrum, jdno, jieyouxu, marcoieni

jieyouxu · 2026-06-10T14:21:26Z

@bors try jobs=optional-x86_64-gnu-parallel-frontend

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-10T14:34:08Z

💔 Test for 93be885 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 526s. The minimum duration for CI workflows is configured to be 600s.

Make parallel frontend CI job compile tests in parallel

jieyouxu · 2026-06-12T14:56:11Z

@bors try

Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-bors · 2026-06-12T15:04:48Z

💔 Test for 1810706 failed: CI. Failed job:

try - optional-x86_64-gnu-parallel-frontend (web logs, enhanced plaintext logs)

A workflow was considered to be a failure because it took only 502s. The minimum duration for CI workflows is configured to be 600s.

rust-log-analyzer · 2026-06-12T15:04:49Z

The job optional-x86_64-gnu-parallel-frontend failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

# Compile each test sequentially to achieve max thread utilization by a single rustc process
ENV RUST_TEST_THREADS 1
# Build the toolchain with multiple parallel frontend threads and then run tests
ENV SCRIPT python3 ../x.py --stage 2 test --set rust.parallel-frontend-threads=4 "--" --parallel-frontend-threads=4 --iteration-count=2
#!/bin/sh
# ignore-tidy-linelength
set -ex
---
x.py completions check
x.py help check
[TIMING:end] test::Tidy { } -- 31.941
[TIMING:start] test::BootstrapPy { }
usage: python3 -m unittest [-h] [-v] [-q] [--locals] [-f] [-c] [-b]
[-k TESTNAMEPATTERNS]
[tests ...]
python3 -m unittest: error: unrecognized arguments: --parallel-frontend-threads=4 --iteration-count=2
Command `/usr/bin/python3 -m unittest bootstrap_test.py --parallel-frontend-threads=4 --iteration-count=2 [workdir=/checkout/src/bootstrap/]` failed with exit code 2
Created at: src/bootstrap/src/core/build_steps/test.rs:3715:35
Executed at: src/bootstrap/src/core/build_steps/test.rs:3727:41
--- BACKTRACE vvv
0: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
2: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
4: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3727:41
5: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::BootstrapPy>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1596:36
6: <bootstrap::core::build_steps::test::BootstrapPy as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:3711:21
7: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
8: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
9: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1139:9
10: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1118:14
11: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:803:25
12: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
13: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:250:5
14: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/sys/backtrace.rs:166:18
15: std::rt::lang_start::<()>::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:206:18
16: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/core/src/ops/function.rs:287:21
17: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
18: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:544:19
19: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panic.rs:359:14
20: std::rt::lang_start_internal::{closure#0}
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/rt.rs:175:24
21: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/0417c25868d6dfbd1c291dfeae950504faa6f790/library/std/src/panicking.rs:581:40
---
28: __libc_start_main
29: _start
Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `--stage 2 test --set rust.parallel-frontend-threads=4 -- --parallel-frontend-threads=4 --iteration-count=2`
Build completed unsuccessfully in 0:01:14
local time: Fri Jun 12 15:04:34 UTC 2026
network time: Fri, 12 Jun 2026 15:04:34 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

petrochenkov · 2026-06-24T10:18:30Z

@zetanumbers is on vacation until July 15, but we want these changes sooner, so #158307 resubmits and tries to fix them.

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

Rollup merge of #158307 - heinwol:parallel-frontend-CI, r=jieyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes #157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

@petrochenkov

CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang/rust#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Make parallel frontend job run test in parallel
7bd7679

rustbot assigned jieyouxu Jun 10, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 10, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
93be885
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 10, 2026

This comment has been minimized.
Sign in to view

a
8b83b78

petrochenkov mentioned this pull request Jun 11, 2026
Add parallel front-end test suite to compiletest #118698
Closed

jieyouxu added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
c416638
Make parallel frontend CI job compile tests in parallel

This comment was marked as off-topic.
Sign in to view

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Jun 12, 2026
Auto merge of#157705- zetanumbers:parallel-tests, r=<try>
1810706
Make parallel frontend CI job compile tests in parallel try-job: optional-x86_64-gnu-parallel-frontend

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2026

heinwol mentioned this pull request Jun 23, 2026
CI job for parallel frontend ui tests #158307
Merged

petrochenkov mentioned this pull request Jun 23, 2026
MCP: Stabilization strategy for rustc parallel frontend rust-lang/compiler-team#1005
Closed
3 tasks

petrochenkov closed this Jun 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2026

Uh oh!

Uh oh!

Conversation

zetanumbers commented Jun 10, 2026• edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 10, 2026

Uh oh!

jieyouxu commented Jun 10, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Jun 10, 2026

Uh oh!

This comment has been minimized.

This comment was marked as off-topic.

This comment has been minimized.

This comment was marked as off-topic.

jieyouxu commented Jun 12, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Jun 12, 2026

Uh oh!

rust-log-analyzer commented Jun 12, 2026

Uh oh!

petrochenkov commented Jun 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

zetanumbers commented Jun 10, 2026• edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 10, 2026

Uh oh!

jieyouxu commented Jun 10, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Jun 10, 2026

Uh oh!

This comment has been minimized.

This comment was marked as off-topic.

This comment has been minimized.

This comment was marked as off-topic.

jieyouxu commented Jun 12, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Jun 12, 2026

Uh oh!

rust-log-analyzer commented Jun 12, 2026

Uh oh!

petrochenkov commented Jun 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

zetanumbers commented Jun 10, 2026• edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 10, 2026

Uh oh!

jieyouxu commented Jun 10, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Jun 10, 2026

zetanumbers commented Jun 10, 2026•
edited by jieyouxu
Loading

zetanumbers commented Jun 10, 2026•
edited by jieyouxu
Loading

zetanumbers commented Jun 10, 2026•
edited by jieyouxu
Loading

zetanumbers commented Jun 10, 2026•
edited by jieyouxu
Loading