Do we need even more agressive validation?

[RalfJung]

Currently, we do not catch this:

#![feature(rustc_attrs)]
#![allow(unused_attributes)]

#[rustc_layout_scalar_valid_range_start(1)]
#[repr(transparent)]
pub(crate) struct NonZero<T>(pub(crate) T);

fn main() {
    let mut x = Some(NonZero(1));
    let xref = match x {
        Some(ref mut c) => c,
        None => panic!(),
    };
    *xref = NonZero(0);
}

In the MIR, the *xref = NonZero(0) becomes an assignment of the only field of this struct, and that field is of type i32 and hence value 0 is no problem.

I could imagine doing validation of prefixes of the path involved in an assignment, but I see no way to catch the following:

fn main() {
    let mut x = Some(unsafe { NonZero(1) }); // this one is fine
    let xref = match x {
        Some(NonZero(ref mut c)) => c,
        None => panic!(),
    };
    *xref = 0; // this one is not
}

This won't even be caught by @oli-obk's new unsafety check for constructing NonZero.

(The last example is not specific to NonZero at all; writing 2 into a &mut bool after casting it to *mut u8 is similar.)

[oli-obk]

aaand now I'm gonna make taking references to fields of rustc_layout_scalar_valid_range_start unsafe, too.

[oli-obk]

cc @Centril ralf found "the next hole". That didn't take very long

[Centril]

Dear lord. =P

[Centril]

PS: I think we can treat these changes as rustc internals that is inconsequential wrt. the language team's review of exposed stable behavior (since it doesn't affect any stable behavior...).

[RalfJung]

Closing in favor of rust-lang/unsafe-code-guidelines#189: this is first and foremost a question of "what is the spec", not how to implement it.