Miri does not get entirely unleashed

[RalfJung]

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

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

use std::cell::UnsafeCell;


struct Meh {
    x: UnsafeCell<i32>,
}

unsafe impl Sync for Meh {}

static MEH: Meh = Meh {
    x: UnsafeCell::new(42),
};

const WRITE: () = unsafe {
    *MEH.x.get() = 12;
};


fn main() {
}

I expected that that should try to mutate a global, and show an error along those lines. But instead, const-checking gets in the way, even though "unleash Miri" should disable that:

warning: skipping const checks
  --> unleash.rs:18:6
   |
18 |     *MEH.x.get() = 12;
   |      ^^^

error[E0019]: constant contains unimplemented expression type
  --> unleash.rs:18:5
   |
18 |     *MEH.x.get() = 12;
   |     ^^^^^^^^^^^^^^^^^

error: aborting due to previous error; 1 warning emitted

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

[RalfJung]

Cc @rust-lang/wg-const-eval

[RalfJung]

Ah, I need to add the const_mut_refs feature gate. But that's basically impossible to figure out without reading the rustc sources.

I think unleashing miri should ignore all those feature gates. IMO it makes little sense to let this unleash features that do not even have a feature gate yet, but not let it unleash features that do.

[ecstatic-morse]

Cross posting from #71631:

The goal of the current behavior is to prevent unnecessary use of -Zunleash in the test suite when feature gates would suffice. Requiring that test writers use feature gates makes it easy to see what tests no longer need -Zunleash when a new feature is implemented on nightly.

Without a diagnostics bug--we were not suggesting that nightly users enable #![feature(const_mut_refs)] when we saw a deref of a mutable reference--the solution to the problem you encountered would have been clear. We should fix this instead.

[RalfJung]

(I responded there, summary: I disagree.)