`static FOO:Foo=FOO;` doesn't cause cycle error for zero-sized-type with no public constructor.

[rodrimati1992]

I tried this code:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b8f15edf4886c9c8bb753636feb70ec2

pub mod foo {
    #[derive(Debug, Copy, Clone)]
    pub struct Foo {
        x: (),
    }
}

pub static FOO: foo::Foo = FOO;

fn main() {
    dbg!(FOO);
}

I expected the code to fail to compile with a cycle error.

Instead, it compiled and ran,printing the value of FOO .

Meta

I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 e82734e) versions.

Trying this code in rust.godbolt.org it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.

[eddyb]

cc @rust-lang/wg-const-eval

[ecstatic-morse]

cargo-bisect-rustc narrowed to the following:

Auto merge of #63015 - Centril:rollup-ydhpcas, r=Centril
Auto merge of #62086 - petrochenkov:builtout, r=eddyb
Auto merge of #62748 - luca-barbieri:optimize-refcell-borrow, r=RalfJung
Auto merge of #63043 - Centril:rollup-f4baee4, r=Centril
Auto merge of #63029 - petrochenkov:rpass, r=Centril

Possibly #62982?

[Centril]

Weaponized soundness hole (using https://docs.rs/refl/0.2.1/refl/ as a foundation):

pub static FOO: refl::Id<usize, Box<u8>> = FOO;

fn main() {
    let x: Box<_> = FOO.cast(42usize);
    drop(x);
}

mod refl {
    pub struct Id<S: ?Sized, T: ?Sized>(core::marker::PhantomData<(fn(S) -> S, fn(T) -> T)>);

    impl<S: ?Sized, T: ?Sized> Copy for Id<S, T> {}
    impl<S: ?Sized, T: ?Sized> Clone for Id<S, T> { fn clone(&self) -> Self { *self } }

    impl<S: ?Sized, T: ?Sized> Id<S, T> {
        /// Casts a value of type `S` to `T`.
        ///
        /// This is safe because the `Id` type is always guaranteed to
        /// only be inhabited by `Id<T, T>` types by construction.
        pub fn cast(self, value: S) -> T where S: Sized, T: Sized {
            unsafe {
                // Transmute the value;
                // This is safe since we know by construction that
                // S == T (including lifetime invariance) always holds.
                let cast_value = core::mem::transmute_copy(&value);
    
                // Forget the value;
                // otherwise the destructor of S would be run.
                core::mem::forget(value);
    
                cast_value
            }
        }
    }
}

==>

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

[Centril]

cc @oli-obk @RalfJung

[RalfJung]

oopsie yeah... #62982 is probably where this started. But that is crucial to fix #62189.

The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for FOO:

static  FOO: foo::Foo = {
    let mut _0: foo::Foo;                // return place in scope 0 at src/main.rs:8:17: 8:25
    let mut _1: &foo::Foo;               // in scope 0 at src/main.rs:8:28: 8:31

    bb0: {
        StorageLive(_1);                 // bb0[0]: scope 0 at src/main.rs:8:28: 8:31
        _1 = const Scalar(alloc0+0): &foo::Foo; // bb0[1]: scope 0 at src/main.rs:8:28: 8:31
                                         // ty::Const
                                         // + ty: &foo::Foo
                                         // + val: Value(Scalar(alloc0+0))
                                         // mir::Constant
                                         // + span: src/main.rs:8:28: 8:31
                                         // + literal: Const { ty: &foo::Foo, val: Value(Scalar(alloc0+0)) }
        _0 = (*_1);                      // bb0[2]: scope 0 at src/main.rs:8:28: 8:31
        StorageDead(_1);                 // bb0[3]: scope 0 at src/main.rs:8:30: 8:31
        return;                          // bb0[4]: scope 0 at src/main.rs:8:1: 8:32
    }
}

So there actually is a *_1 that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.