Skip to content

Make parallel frontend CI job compile tests in parallel#157705

Closed
zetanumbers wants to merge 2 commits into
rust-lang:mainfrom
zetanumbers:parallel-tests
Closed

Make parallel frontend CI job compile tests in parallel#157705
zetanumbers wants to merge 2 commits into
rust-lang:mainfrom
zetanumbers:parallel-tests

Conversation

@zetanumbers

@zetanumbers zetanumbers commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

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 rustbot added A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. labels Jun 10, 2026
@rustbot

rustbot commented Jun 10, 2026

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Member

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

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Jun 10, 2026
Make parallel frontend CI job compile tests in parallel


try-job: optional-x86_64-gnu-parallel-frontend
@rust-bors rust-bors Bot 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
@rust-bors

rust-bors Bot commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

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

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

@rust-log-analyzer

This comment has been minimized.

@jieyouxu 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
@jieyouxu

This comment was marked as off-topic.

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Jun 12, 2026
Make parallel frontend CI job compile tests in parallel
@rust-bors

This comment was marked as off-topic.

@jieyouxu

Copy link
Copy Markdown
Member

@bors try

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Jun 12, 2026
Make parallel frontend CI job compile tests in parallel

try-job: optional-x86_64-gnu-parallel-frontend
@rust-bors rust-bors Bot 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
@rust-bors

rust-bors Bot commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

💔 Test for 1810706 failed: CI. Failed job:

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

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Contributor

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

@rustbot 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
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 8, 2026
…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
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 8, 2026
…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
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 8, 2026
…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
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 8, 2026
…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
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 8, 2026
…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
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 9, 2026
…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
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 9, 2026
…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
rust-timer added a commit that referenced this pull request Jul 9, 2026
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
pull Bot pushed a commit to xtqqczze/rust-lang-miri that referenced this pull request Jul 10, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants