Compiler unit tests are never run in CI

[jyn514]

I tried this code on a checkout branched from f5e2df7:

$ x test compiler/rustc_parse_format

I expected to see this happen: No warnings.

Instead, this happened:

Testing stage1 {rustc_parse_format} (aarch64-apple-darwin)
   Compiling rustc_index v0.0.0 (/Users/jyn/src/rust-upstream/compiler/rustc_index)
warning: extern crate `smallvec` is unused in crate `rustc_index`
 --> compiler/rustc_index/src/lib.rs:2:1
  |
2 | #![cfg_attr(all(feature = "nightly", test), feature(stmt_expr_attributes))]
  | ^
  |
  = help: remove the dependency or add `use smallvec as _;` to the crate root
  = note: requested on the command line with `-W unused-crate-dependencies`

This in itself isn't a big deal, but it seems bad that we aren't running tests that would have caught this ... I spot-checked the logs for the latest bors merge (https://github.com/rust-lang/rust/actions/runs/18907890296/job/53970647517) and couldn't find rustc_parse_format anywhere in them.

[ehuss]

The only way to fully test this would be to use something like cargo hack (or have bootstrap do that), which I think would be very expensive.

An alternative would be to use cargo's unstable feature unification to force all features to be used, but I would not advise that.

latest bors merge (https://github.com/rust-lang/rust/actions/runs/18907890296/job/53970647517) and couldn't find rustc_parse_format anywhere in them.

It should be in every test job. The output looks like:

     Running unittests src/lib.rs (obj/build/x86_64-unknown-linux-gnu/stage2-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_parse_format-0d34affbc57d2d93)

[jyn514]

👍 confirmed that I found 2025-10-29T14:06:05.3428480Z �[1m�[92m Running�[0m unittests src/lib.rs (build/aarch64-apple-darwin/stage2-rustc/aarch64-apple-darwin/release/deps/rustc_parse_format-5df9f1fcc77c3f18) in the job I linked, github's search is just garbage.

I've figured out what happened here. Ferrocene has a hack downstream called --ferrocene-test-one-crate-per-cargo-call, which is the equivalent of running for crate in compiler/*; x test $crate; done, but more efficient. Rust's CI doesn't do this; instead it does something like x test compiler/*. The latter has one cargo invocation, not many, so it doesn't catch issues like the one I posted.

The only way to fully test this would be to use something like cargo hack (or have bootstrap do that), which I think would be very expensive.

In the general case, yes — but we don't have to test every combination of feature, I think having one job where we run all the tests in a single cargo invocation, and one job where we run them with one invocation per crate is doable and wouldn't even add much more CI time.

That said I don't feel strongly about this, happy for Ferrocene to catch this downstream.