Incorrect detection of compilation failures when there's a panic in const evaluation.

[LouisGariepy]

Doctests that yield a compile-time error due to a panic in a const evaluation are buggy under MIRI. As an example, consider the following code:

pub struct Foo<const N: usize>;

impl<const N: usize> Foo<N> {
    const N_GT_ZERO: () = assert!(N > 0);

    /// ```rust,compile_fail
    /// use blackboard::Foo;
    ///
    /// let foo = Foo::<0>::new();
    /// ```
    pub fn new() -> Self {
        // This will cause a panic at const-time if `N == 0`
        let _ = Self::N_GT_ZERO;
        Self
    }
}

Running cargo test informs us that the one doc test passed.

Now, running cargo +nightly miri test instead marks the test as failed (i.e. MIRI thinks it somehow compiled successfully)

Test compiled successfully, but it's marked `compile_fail`.

Removing the compile_fail annotation and rerunning miri also fails (because of the intended compilation error).

It seems like there might be a wart in how compile_fail doctests are handled by MIRI.

[saethlin]

The problem isn't with doctests, it's a fundamental problem with how Miri works (currently?). Your example can be rewritten as:

pub struct Foo<const N: usize>;

impl<const N: usize> Foo<N> {
    const N_GT_ZERO: () = assert!(N > 0);

    pub fn new() -> Self {
        // This will cause a panic at const-time if `N == 0`
        let _ = Self::N_GT_ZERO;
        Self
    }
}

fn main() {
    let foo = Foo::<0>::new();
}

Then if you try to run it with cargo miri run, you'll see something like this:

Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)... done
   Compiling scratch v0.1.0 (/tmp/scratch)
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/scratch`

The program "builds" successfully, and fails at runtime. All const eval and post-mono errors are runtime errors to Miri.

[LouisGariepy]

@saethlin Thanks for the insight!

I amended the title to make the situation a bit clearer. Feel free to modify it further if it's not appropriate.

I imagine the next step is to determine if this is a "wontfix" or if there's an actionable path forward.

[saethlin]

I think this is a duplicate of #2423 (I looked for that issue earlier and came up empty).

That other Miri issue links to a rust-lang/rust issue which has some PRs linked to it. We'd like to fix this, but don't hold your breath. You might be able to use #[cfg(not(miri))] to work around this limitation for now.