rustc version:
rustc 1.95.0-nightly (c78a29473 2026-02-22)
description:
Running cargo miri with -Zmiri-report-progress causes a panic on a simple function. The panic appears to be triggered when MIRI attempts to report the currently executing location for certain basic blocks that carry no source location in the MIR.
reproduction:
fn main() {
let _r = foo(0, 0);
}
fn foo(i: i32, j: i32) -> i32 {
if i % 2 == 0 {
return if j % 2 == 0 { 1 } else { 2 };
}
if j % 2 == 0 {
return if i % 2 == 0 { 3 } else { 4 };
}
5
}
MIRIFLAGS="-Zmiri-report-progress=1" cargo +nightly miri run
cause:
Inspecting the MIR dump (e.g. via RUSTFLAGS="-Zdump-mir=foo") reveals that some basic blocks, specifically at early return, contain a terminator annotated with no-location. When -Zmiri-report-progress is sufficiently small, once MIRI tries to emit the location of the terminator, it fails.
In my opinion, MIRI can emit the closest statement location or whole scope of the basic block instead. I would love to work on fixing this issue if that would be welcome.
rustc version:
rustc 1.95.0-nightly (c78a29473 2026-02-22)
description:
Running cargo miri with -Zmiri-report-progress causes a panic on a simple function. The panic appears to be triggered when MIRI attempts to report the currently executing location for certain basic blocks that carry no source location in the MIR.
reproduction:
MIRIFLAGS="-Zmiri-report-progress=1" cargo +nightly miri runcause:
Inspecting the MIR dump (e.g. via RUSTFLAGS="-Zdump-mir=foo") reveals that some basic blocks, specifically at early return, contain a terminator annotated with no-location. When -Zmiri-report-progress is sufficiently small, once MIRI tries to emit the location of the terminator, it fails.
In my opinion, MIRI can emit the closest statement location or whole scope of the basic block instead. I would love to work on fixing this issue if that would be welcome.