Skip to content

library/test: always enable unstable features for miri #153369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rust-bors merged 1 commit into from
Mar 5, 2026
Merged

library/test: always enable unstable features for miri #153369

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions library/test/build.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,11 +2,16 @@ fn main() {
println!("cargo:rerun-if-changed=build.rs");
println!("cargo:rustc-check-cfg=cfg(enable_unstable_features)");

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.
Copy link
Member

@RalfJung RalfJung Mar 5, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

// 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() || {
Copy link
Member

@RalfJung RalfJung Mar 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@RalfJung RalfJung Mar 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

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();
stdout.contains("nightly") || stdout.contains("dev")
};

if stdout.contains("nightly") || stdout.contains("dev") {
if enable_unstable_features {
println!("cargo:rustc-cfg=enable_unstable_features");
}
}
Loading