Program that uses the `const VOID: ! =panic!()` associated constant compiles and runs into illegal intruction.

[rodrimati1992]

This unsound code compiles in the playground (on Rust nightly 2019-12-01):

#![feature(const_panic)]

struct PrintName;

impl PrintName {
    const VOID: ! = panic!();
}

fn main() {
    let _ = PrintName::VOID;
}

And runs into an illegal instruction:

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 0.65s
     Running `target/debug/playground`
timeout: the monitored command dumped core
/root/entrypoint.sh: line 8:     7 Illegal instruction     timeout --signal=KILL ${timeout} "$@"

I expected this to fail to compile because panicking in constants should cause compilation errors.

[Centril]

cc @rust-lang/wg-const-eval

[oli-obk]

Ok, there's three questionable things going on.

1. Why do we get an error if it's not an associated constant but just a normal constant
2. It also happens for normal constants with allow(const_err)

#![feature(const_panic)]
#![allow(const_err)]

const VOID: ! = panic!();

fn main() {
    let _ = VOID;
}

3. It does not happen for arithmetic panics

#![allow(const_err)]

const VOID: u32 = 0 - 1;

fn main() {
    let x = VOID; // still an error
}

[oli-obk]

Ok... so I did a full MIR dump of the example code and even the very first MIR directly after mir building does not contain the assignment (although it contains the variable of ! type). I'm not sure what we're doing here, but it seems mir building must already bail out of building this assignment, because it knows it's dead.

[matthewjasper]

We throw the constant on the floor:

rust/src/librustc_mir/build/expr/into.rs

Line 68 in e862c01

unpack!(block = this.as_local_rvalue(block, source));

This needs to be as_temp to ensure that anything ends up in the MIR.

[oli-obk]

Wouldn't as_temp change the behaviour of let _ = ...; to let _tmp = ...;, thus affecting the drop behaviour if the assign rhs is a temporary value?

[matthewjasper]

as_temp takes the scope of the temporary that it creates. We generate an Unreachable terminator right after this, so I don't think that it matters much either way.

[RalfJung]

FWIW I don't think this is unsound; this just runs into the safety net that we have when embedding consts/promoteds with errors into the code -- we emit a trap. So this is certainly wrong codegen but I don't think there is any UB.

[oli-obk]

It is unsound, because we don't run into the promoted safety net. The constant never even shows up in MIR, instead all it is is a basic block with an unreachable terminator.

@matthewjasper my worry was not about this specific code miscompiling, but other code miscompiling. But you're right, the call you found only is run for never types. Can you open a PR with the change and a mir opt test showing that it doesn't get optimized away? This may additionally require #67134

[RalfJung]

It is unsound, because we don't run into the promoted safety net. The constant never even shows up in MIR, instead all it is is a basic block with an unreachable terminator.

Oh. Yeah okay that's pretty bad indeed.