Miri executing code with errors

[matthiaskrgr]

struct Struct<T>(T);

impl<T> std::ops::Deref for Struct<T> {
    type Target = dyn Fn(T);
    fn deref(&self) -> &assert_mem_uninitialized_valid::Target {
        unimplemented!()
    }
}

fn main() {
    let f = Struct(Default::default());
    f(0);
    f(0);
}

MIRIFLAGS=-Zmiri-backtrace=full RUSTFLAGS="-Zmir-opt-level=0" ~/.cargo/bin/cargo miri run

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
WARNING: Ignoring `RUSTC_WRAPPER` environment variable, Miri does not support wrapping.
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `/home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/mri`
error: post-monomorphization error: the type has an unknown layout
  --> src/main.rs:12:5
   |
12 |     f(0);
   |     ^ the type has an unknown layout
   |
   = note: inside `main` at src/main.rs:12:5: 12:6
   = note: inside `<fn() as std::ops::FnOnce<()>>::call_once - shim(fn())` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
   = note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:155:18: 155:21
   = note: inside closure at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:166:18: 166:82
   = note: inside `std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:284:13: 284:31
   = note: inside `std::panicking::r#try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:555:40: 555:43
   = note: inside `std::panicking::r#try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:519:19: 519:81
   = note: inside `std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14: 142:33
   = note: inside closure at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:48: 148:73
   = note: inside `std::panicking::r#try::do_call::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:555:40: 555:43
   = note: inside `std::panicking::r#try::<isize, {closure@std::rt::lang_start_internal::{closure#2}}>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:519:19: 519:81
   = note: inside `std::panic::catch_unwind::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14: 142:33
   = note: inside `std::rt::lang_start_internal` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:20: 148:98
   = note: inside `std::rt::lang_start::<()>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:165:17: 170:6

error[E0433]: failed to resolve: use of undeclared crate or module `assert_mem_uninitialized_valid`
 --> src/main.rs:5:25
  |
5 |     fn deref(&self) -> &assert_mem_uninitialized_valid::Target {
  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared crate or module `assert_mem_uninitialized_valid`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0433`.

with mir-opt-level 3, this reports UB:

MIRIFLAGS=-Zmiri-backtrace=full RUSTFLAGS="-Zmir-opt-level=3" ~/.cargo/bin/cargo miri run

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
WARNING: Ignoring `RUSTC_WRAPPER` environment variable, Miri does not support wrapping.
   Compiling mri v0.1.0 (/tmp/mri)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `/home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/mri`
warning: You have explicitly enabled MIR optimizations, overriding Miri's default which is to completely disable them. Any optimizations may hide UB that Miri would otherwise detect, and it is not necessarily possible to predict what kind of UB will be missed. If you are enabling optimizations to make Miri run faster, we advise using cfg(miri) to shrink your workload instead. The performance benefit of enabling MIR optimizations is usually marginal at best.

error: Undefined Behavior: entering unreachable code
  --> src/main.rs:5:5
   |
5  |     fn deref(&self) -> &assert_mem_uninitialized_valid::Target {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ entering unreachable code
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
   = note: BACKTRACE:
   = note: inside `<Struct<i32> as std::ops::Deref>::deref` at src/main.rs:5:5: 5:63
note: inside `main`
  --> src/main.rs:12:5
   |
12 |     f(0);
   |     ^
   = note: inside `<fn() as std::ops::FnOnce<()>>::call_once - shim(fn())` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
   = note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:155:18: 155:21
   = note: inside closure at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:166:18: 166:82
   = note: inside `std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:284:13: 284:31
   = note: inside `std::panicking::r#try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:555:40: 555:43
   = note: inside `std::panicking::r#try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:519:19: 519:81
   = note: inside `std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14: 142:33
   = note: inside closure at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:48: 148:73
   = note: inside `std::panicking::r#try::do_call::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:555:40: 555:43
   = note: inside `std::panicking::r#try::<isize, {closure@std::rt::lang_start_internal::{closure#2}}>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:519:19: 519:81
   = note: inside `std::panic::catch_unwind::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14: 142:33
   = note: inside `std::rt::lang_start_internal` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:20: 148:98
   = note: inside `std::rt::lang_start::<()>` at /home/matthias/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:165:17: 170:6

error[E0433]: failed to resolve: use of undeclared crate or module `assert_mem_uninitialized_valid`
 --> src/main.rs:5:25
  |
5 |     fn deref(&self) -> &assert_mem_uninitialized_valid::Target {
  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared crate or module `assert_mem_uninitialized_valid`

error: aborting due to 2 previous errors; 1 warning emitted

For more information about this error, try `rustc --explain E0433`.

which is interesting given that the code not even passes cargo check 🤔

error[E0433]: failed to resolve: use of undeclared crate or module `assert_mem_uninitialized_valid`
 --> src/main.rs:5:25
  |
5 |     fn deref(&self) -> &assert_mem_uninitialized_valid::Target {
  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ use of undeclared crate or module `assert_mem_uninitialized_valid`

For more information about this error, try `rustc --explain E0433`.
error: could not compile `mri` (bin "mri") due to 1 previous error

[Noratrieb]

lol, that is some, uh, wild error recovery for sure! @rust-lang/miri Miri should probably not execute code when there are errors :D

[RalfJung]

We're asking rustc if there are any errors, and apparently it says no.^^

[Noratrieb]

💀

[matthiaskrgr]

could be related to #121129 maybe?
There were a lot of changes to error handling recently 😅

[RalfJung]

I would be surprised if it's that, we do have a test for not executing when there are errors and this passes. So maybe this is a different kind of error that evades that check? Not sure how though.

Still, Cc @nnethercote

[nnethercote]

could be related to #121129 maybe? There were a lot of changes to error handling recently 😅

Unlikely to be #121129, but #121206 is a definite contender. It's Saturday morning here, I will take a look on Monday.

[nnethercote]

We're asking rustc if there are any errors, and apparently it says no.^^

This is almost certainly going to be related to changes I've made in the handling of stashed diagnostics. I'm now at the point where I really hate stashed diagnostics. They used to be eagerly counted as errors, even though they could be cancelled, which was a huge soundness hole in how ErrorGuaranteed worked. So I fixed that in #120828. But now we have the opposite problem, where it's easy to forget about stashed diagnostics, and conclude that no errors have been issued when there is a stashed diagnostic pending. Argh.

[nnethercote]

I'm now heading in a direction where stashed errors are not allowed to be cancelled, but also counted as soon as they are stashed. I think that will be a good middle ground.

[Noratrieb]

That makes sense to me. You can't cancel an emit()ted diagnostic either, and stash is just emit-but-maybe-modify-later.

[nnethercote]

How can I build and run a local miri? I did x build src/tools/miri --stage 2 and tried to run the resulting binary but hit things involving sysroots and cargo miri and I don't know how to proceed.

[saethlin]

You should x build miri cargo-miri then use cargo +stageN miri run.

Miri is not usable on its own like rustc is because the rustc sysroot is always bundled, the Miri one is not.

[nnethercote]

Thanks! Is this written down somewhere?

[saethlin]

Considering how much the dev guide slips here and there I'm pretty sure it's not. Most work on Miri is done out-of-tree and therefore doesn't go through bootstrap. So unfortunately the in-tree workflows don't get the attention they deserve.

[RalfJung]

You should x build miri cargo-miri then use cargo +stageN miri run.

I didn't even know that one. oO

You can run individual files with ./x.py miri --stage 0 run --args <filename>.

Where should this be documented?