library/test: always enable unstable features for miri by cuviper · Pull Request #153369 · rust-lang/rust

cuviper · 2026-03-03T21:49:34Z

The unstable features of the test crate used to be default-enabled,
and manually disabled when building the beta and stable channels. Commit
dae8ea9 flipped that to default-disabled, only enabled for nightly
and dev channels.

However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build. Now the test build script makes that happen by
noticing the MIRI_CALLED_FROM_SETUP environment variable.

The unstable features of the `test` crate used to be default-enabled, and manually disabled when building the beta and stable channels. Commit dae8ea9 flipped that to default-disabled, only enabled for nightly and dev channels. However, this broke miri testing on the beta/stable channels, because it also uses unstable features -- which should be fine to enable just for its own sysroot build. Now the `test` build script makes that happen by noticing the `MIRI_CALLED_FROM_SETUP` environment variable.

rustbot · 2026-03-03T21:49:39Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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 7 candidates
Random selection from Mark-Simulacrum, joboet, tgross35

cuviper · 2026-03-03T21:50:17Z

1.95-beta is currently blocked on this problem: #153314 (comment)

@rustbot label +beta-nominated

jieyouxu

This looks reasonable to me (but am neither a libs reviewer nor miri reviewer).

View changes since this review

Kobzol · 2026-03-04T07:06:41Z

I looked at this again and I guess that this is a natural consequence of flipping the default, before we used to use unstable features in some places "by accident", such as in Miri, while they need an explicit opt-in. Would be nicer to set this for Miri tests from bootstrap, rather than in the build probe, but I guess that this would still break miri when executed outside of bootstrap?

I think that as a hotfix for beta this is good enough.

You can r=me if you tested that this unblocks the beta build (the miri test on stable/beta).

cuviper · 2026-03-04T23:16:53Z

I had tested that locally, but I went ahead and added this to #153314 for beta to confirm, and it did pass miri's PR CI. Also, T-libs folks are showing approval for the backport on zulip.

@rustbot label +beta-accepted
@bors r=Kobzol

rust-bors · 2026-03-04T23:16:55Z

📌 Commit 30d7ed4 has been approved by Kobzol

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

cuviper · 2026-03-04T23:34:48Z

Would be nicer to set this for Miri tests from bootstrap, rather than in the build probe, but I guess that this would still break miri when executed outside of bootstrap?

Yes, I think a bootstrap-only fix would break miri elsewhere -- except we don't ship miri on stable or beta anyway. So maybe that's fine, although I'm not sure how else bootstrap would help this, because it has to do with how miri builds test in its own target sysroot.
cc @rust-lang/miri

[beta] prepare Rust 1.95.0-beta Ref: https://forge.rust-lang.org/release/process.html#beta-pr - Replace version placeholders with 1.95.0 - Bump to beta release - library/test: always enable unstable features for miri #153369 r? cuviper

RalfJung · 2026-03-05T07:51:27Z

I am very surprised Miri is even built, let alone run, on beta/stable branches. It's a nightly-only tool after all.

However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build.

Any idea which flag this is about? I don't think Miri passes any of its own arguments to the test runner. We pass stuff to cargo and rustc of course but that should work thanks to RUSTC_BOOTSTRAP.

RalfJung · 2026-03-05T08:11:13Z

library/test/build.rs

-    let stdout = String::from_utf8(version.stdout).unwrap();
+    // Miri testing uses unstable features, so always enable that for its sysroot.
+    // Otherwise, only enable unstable if rustc looks like a nightly or dev build.
+    let enable_unstable_features = std::env::var("MIRI_CALLED_FROM_SETUP").is_ok() || {


Note that MIRI_CALLED_FROM_SETUP is considered an internal env var of cargo-miri, it's something we might rearrange any time.

A better env varo to check would be CARGO_CFG_MIRI. That's the build script way of checking whether --cfg miri is enabled in the crate itself.

Or you could use cfg!(miri) in the crate itself.

But I'd still like to understand why this is even needed...

RalfJung · 2026-03-05T08:15:01Z

library/test/build.rs

-    let rustc = std::env::var("RUSTC").unwrap_or_else(|_| "rustc".into());
-    let version = std::process::Command::new(rustc).arg("-vV").output().unwrap();
-    let stdout = String::from_utf8(version.stdout).unwrap();
+    // Miri testing uses unstable features, so always enable that for its sysroot.


I don't think we use any unstable features of the libtest harness. So, no idea what's happening here. Is cargo forwarding the -Zunstable-features (that is just meant to enable unstable cargo features) to libtest? Why does the RUSTC_BOOTSTRAP that bootstrap sets not suffice (it apparently suffices for cargo)?

…uwer Rollup of 8 pull requests Successful merges: - #153361 (enable `PassMode::Indirect { on_stack: true, .. }` tail call arguments) - #153369 (library/test: always enable unstable features for miri) - #152283 (Properly pass offload sizes to kernel args) - #153323 (Remove `impl QueryVTable`) - #153385 (Fix comment on `is_horizontal_whitespace`) - #153394 (fix(thir): Include `NoneWithError` in Enum Struct Tail Assertion) - #153419 (rustc_llvm: add missing `-` to flag-comparison logic) - #153423 (Update dispatch2 to v0.3.1)

RalfJung · 2026-03-05T11:09:34Z

Since this happens when invoking Miri on the libcore test suite, I can only assume that bootstrap itself passes some unstable arguments to the test suite. And then the check for the RUSTC_BOOTSTRAP env var inside libtest doesn't work because Miri runs in isolation mode, not giving the program access to environment variables on the host.

I see two options:

we add -Zmiri-env-forward=RUSTC_BOOTSTRAP so that the test runner can access the env var set by bootstrap
we always allow unstable options in libtest when cfg!(miri) is set

I'd prefer the first option; the second one relies on Miri currently being always-unstable but it'd be easy to forget about updating this if that ever changes. It's also conceptually wrong -- the reason this works without Miri is the RUSTC_BOOTSTRAP; let's make that also the reason it works with Miri.

RalfJung · 2026-03-05T11:13:57Z

I opened #153437 as my proposed alternative to this PR.

But I'm also fine with landing this for now so we can get the beta out of the door, and then later revert this PR and land mine.

Rollup merge of #153369 - cuviper:unstable-libtest, r=Kobzol library/test: always enable unstable features for miri The unstable features of the `test` crate used to be default-enabled, and manually disabled when building the beta and stable channels. Commit dae8ea9 flipped that to default-disabled, only enabled for nightly and dev channels. However, this broke miri testing on the beta/stable channels, because it also uses unstable features -- which should be fine to enable just for its own sysroot build. Now the `test` build script makes that happen by noticing the `MIRI_CALLED_FROM_SETUP` environment variable.

rustbot assigned Mark-Simulacrum Mar 3, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 3, 2026

rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Mar 3, 2026

jieyouxu approved these changes Mar 4, 2026

View reviewed changes

rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Mar 4, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 4, 2026

cuviper mentioned this pull request Mar 5, 2026

[beta] prepare Rust 1.95.0-beta #153314

Merged

cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Mar 5, 2026

JonathanBrouwer mentioned this pull request Mar 5, 2026

Rollup of 8 pull requests #153430

Merged

RalfJung reviewed Mar 5, 2026

View reviewed changes

RalfJung mentioned this pull request Mar 5, 2026

coretest in miri: fix using unstable libtest features #153437

Open

rust-bors bot merged commit 2feb90a into rust-lang:main Mar 5, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Mar 5, 2026

Uh oh!

Conversation

cuviper commented Mar 3, 2026

Uh oh!

rustbot commented Mar 3, 2026

Uh oh!

cuviper commented Mar 3, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol commented Mar 4, 2026

Uh oh!

cuviper commented Mar 4, 2026

Uh oh!

rust-bors bot commented Mar 4, 2026

Uh oh!

cuviper commented Mar 4, 2026

Uh oh!

RalfJung commented Mar 5, 2026

Uh oh!

RalfJung Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Mar 5, 2026

Uh oh!

RalfJung commented Mar 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jieyouxu left a comment •

edited by rustbot

Loading

RalfJung Mar 5, 2026 •

edited

Loading