libtest: never iterate over all tests in `--exact` mode by RalfJung · Pull Request #161868 · rust-lang/rust

RalfJung · 2026-08-27T12:59:04Z

This should help with rust-lang/miri#5013:

When running cargo miri nextest, nextest spawns one Miri instance for each test of the crate. If the crate has a lot of tests, a non-trivial amount of time is spent in the test harness before it even starts running the test. Turns out almost half that time is spent just making copies of all the TestDescAndFn. That seems silly, we have a perfectly fine static array of those sitting around in the code generated by --test expansion, let's just use references to that array.

So this changes the TestList used to represent the unfiltered list of tests to use borrowed rather than owned types. That changes ripples outwards. The entry points used by the --test harness remain mostly unchanged (except that I renamed them as the old name did not make sense), but rustdoc has been using the old fully-owned API.

Rustdoc has two codepaths, "standalone" and "merged".

For "merged", the fix is easy -- like the --test harness, this can just generate a static array full of StaticTestFn rather than populating a Vec at runtime.
For "standalone", things are more tricky. We need to construct an &[&TestDescAndFn], which requires filling a new vector with references to the entries of an existing Vec<TestDescAndFn>. This also fundamentally relies on the support for dynamic test functions in libtest. Those must now always be cloneable, so they are now internally stored in Arc and must be Fn, not FnOnce. So compared to before there's now one more big Vec to fill with references to all tests, as well as some Arc::clone. OTOH this mode runs a full separate process for each test so I doubt this extra cost is noticeable.
The alternative is to keep support for FnOnce dynamic tests in libtest, which is highly non-trivial due to having to plumb multiple layers of Cow-like handling through everything. I don't think it's worth it, given that dynamic tests are only used by "standalone" rustdoc and by the tests testing libtest.

Overall this saves more than 1s when running coretests (which has 2787 tests) with a hot incremental cache with --exact char::test_is_numeric.
Before: 7.606s
After: 6.484s
Given that most of that time is actually spent in rustc, not in the interpreter, that is a very big speedup for the interpreter part.

rustbot · 2026-08-27T12:59:10Z

r? @JohnTitor

rustbot has assigned @JohnTitor.
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: libs
libs expanded to 12 candidates
Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, joboet, nia-e

RalfJung · 2026-08-27T14:59:49Z

I am not sure what is going on with rustdoc. Even with ./x check --stage 2 src/librustdoc, it seems to not pick up my libtest changes. @rust-lang/rustdoc is that expected?

Also I noticed the test closures rustdoc uses for the "standalone" codepath rely on their FnOnce nature quite a bit. Making them cloneable (in an Arc<Fn>) could be tricky (and it doesn't help that I can't even compile rustdoc against the new libtest to check if this builds). Keeping non-clonable functions supported in libtest is also annoying. Not sure which one is the lesser evil...

GuillaumeGomez · 2026-08-27T15:01:21Z

Didn't look but isn't it a bootstrap issue?

RalfJung · 2026-08-27T15:04:49Z

I don't know. I'm not sure what the expected behavior even is.

It may be a download-rustc problem. I'm now trying with that turned off.
EDIT: Yeah that was it.

RalfJung · 2026-08-27T15:17:34Z

Okay, I think rustdoc should compile again. We'll see if I adjusted the auto-generated code correctly, that's harder to test.^^

The "standalone" codepath has extra overhead now, there's some more cloning. My understanding is that the "merged" codepath is the preferred one so I hope that's fine.

rustbot · 2026-08-27T15:47:42Z

rustc-dev-guide is developed in its own repository. If possible, consider making this change to rust-lang/rustc-dev-guide instead.

cc @BoxyUwU, @tshepang

rustbot · 2026-08-27T20:47:26Z

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

rust-log-analyzer · 2026-09-15T04:09:46Z

The job dist-x86_64-msvc failed! Check out the build log: (web) (plain enhanced) (plain)

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

rust-bors · 2026-09-15T04:14:49Z

💔 Test for 29adbb8 failed: CI. Failed job:

auto - dist-x86_64-msvc (web logs, enhanced plaintext logs)

RalfJung · 2026-09-15T05:26:00Z

There's no error visible in that log, it just cuts off at some point.

@bors retry

…uwer Rollup of 12 pull requests Successful merges: - #160911 (Remove d32 feature from 32-bit Arm targets) - #161868 (libtest: never iterate over all tests in `--exact` mode) - #162771 (Filter do_not_recommend impls before handling a single candidate) - #162779 (rustdoc: Revert "fix bare urls split text") - #161548 (hir_typeck: Don't ICE on closures without drop location in closure capture lint) - #161612 (std: make a lot of items crate private) - #162204 (Suggest keyword order for `extern "C" const unsafe fn`) - #162372 (Clean up `test/rustdoc-html` folder by moving tests where appropriate) - #162638 (dont suggest changing the mutability of a borrow that comes from a macro) - #162643 (Fix `path_trailing_sep` methods for Windows verbatim paths) - #162654 (Improve Armv7-R documentation) - #162784 (AGENTS.md: Permit local experimentation, per the online policy.)

RalfJung · 2026-09-15T08:38:28Z

@bors try jobs=dist-x86_64-msvc

rust-bors · 2026-09-15T08:38:34Z

⌛ Trying commit cae9fb4 with merge f3337a8…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/34948086607

libtest: never iterate over all tests in `--exact` mode try-job: dist-x86_64-msvc

Rollup merge of #161868 - RalfJung:libtest-less-alloc, r=Mark-Simulacrum libtest: never iterate over all tests in `--exact` mode This should help with rust-lang/miri#5013: When running `cargo miri nextest`, nextest spawns one Miri instance for each test of the crate. If the crate has a lot of tests, a non-trivial amount of time is spent in the test harness before it even starts running the test. Turns out almost half that time is spent just making copies of all the `TestDescAndFn`. That seems silly, we have a perfectly fine static array of those sitting around in the code generated by `--test` expansion, let's just use references to that array. So this changes the `TestList` used to represent the unfiltered list of tests to use borrowed rather than owned types. That changes ripples outwards. The entry points used by the `--test` harness remain mostly unchanged (except that I renamed them as the old name did not make sense), but rustdoc has been using the old fully-owned API. Rustdoc has two codepaths, "standalone" and "merged". - For "merged", the fix is easy -- like the `--test` harness, this can just generate a static array full of `StaticTestFn` rather than populating a `Vec` at runtime. - For "standalone", things are more tricky. We need to construct an `&[&TestDescAndFn]`, which requires filling a new vector with references to the entries of an existing `Vec<TestDescAndFn>`. This also fundamentally relies on the support for dynamic test functions in libtest. Those must now always be cloneable, so they are now internally stored in `Arc` and must be `Fn`, not `FnOnce`. So compared to before there's now one more big `Vec` to fill with references to all tests, as well as some `Arc::clone`. OTOH this mode runs a full separate process for each test so I doubt this extra cost is noticeable. The alternative is to keep support for `FnOnce` dynamic tests in libtest, which is highly non-trivial due to having to plumb multiple layers of `Cow`-like handling through everything. I don't think it's worth it, given that dynamic tests are only used by "standalone" rustdoc and by the tests testing libtest. Overall this saves more than 1s when running coretests (which has 2787 tests) with a hot incremental cache with `--exact char::test_is_numeric`. Before: 7.606s After: 6.484s Given that most of that time is actually spent in rustc, not in the interpreter, that is a very big speedup for the interpreter part.

RalfJung · 2026-09-15T10:42:56Z

@bors try cancel

rust-bors · 2026-09-15T10:42:59Z

Try build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/34948086607

Hint: if you want to run another try build, you do not need to manually cancel the previous one. Just run @bors try and bors will cancel the previous build automatically.

@Mark-Simulacrum