ICE with unleash-miri: mutable allocation in constant

[RalfJung]

I tried this code with -Zunleash-the-miri-inside-of-you:

// compile-flags: -Zunleash-the-miri-inside-of-you

#![feature(const_raw_ptr_deref)]
#![feature(const_mut_refs)]
#![allow(const_err)]

use std::cell::UnsafeCell;

// make sure we do not just intern this as mutable
const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _;

fn main() {
}

This is a variant of the mutable_const test.

I am getting an ICE:

error: internal compiler error: mutable allocation in constant
  --> ice.rs:10:1
   |
10 | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17

Cc @rust-lang/wg-const-eval

[RalfJung]

Hm okay in another case it looks like we are actually expecting an ICE with miri-unleash? That seems rather extreme though.

[oli-obk]

I thought that was the intent 😆 The miri-engine doesn't need to gracefully error in situations that can only occur in unleash mode. There's no way a user will ever see it unless we have a bug in either our knowledge of the engine or the static checks.

[RalfJung]

That doesn't match what we do elsewhere though; CTFE doesn't ICE when it hits a box on inline assembly or a non-const fn-call.

This error is slightly different though... it is entirely unclear (to me at least) what the intended behavior is here. On the one hand the user asked for interior mutability, on the other hand it's a const. Any of the following three behaviors seems reasonable:

• Just make this a mutable allocation and let the const point to it (as if it was an "anonymous static" or so).
• Just make this an immutable allocation, so if the user writes to it later that's UB. This is potentially surprising though since they did use UnsafeCell.
• Give a nice error instead of ICEing.

[RalfJung]

Curiously, mutable_references_ice ICEs in a different way. The issues seem related though. It would be nice if they could all go through the same error path.

[oli-obk]

of these three options I'd choose the nice error. I'd rather bail out than introduce mutability to constants.

[RalfJung]

I am getting the feeling that that check is overzealous... we also get an ICE for this constant, which arguably is fine:

const MUTABLE_BEHIND_RAW: *const Vec<i32> = &Vec::<i32>::new() as *const _;

[RalfJung]

In other words, the current const check in the leftover_allocations phase has nothing to do with mutability. These allocations will all be mutable, because all allocations start as mutable and then get frozen when initialization is done. We are right now just rejecting all leftover (untyped) allocations in consts because we cannot sanity-check them. That's not unreasonable, but it is not what the error message says.

[RalfJung]

In fact, this ICEs on stable:

#![allow(const_err)]

const CONST_RAW: *const Vec<i32> = &Vec::new() as *const _;

fn main() {}