Writing to a static is somehow allowed while initializing that same static

[theemathas]

I tried this code:

#![allow(dead_code)]

struct Foo {
    x: i32,
    y: (),
}

static S: Foo = Foo {
    x: 0,
    y: unsafe {
        (&raw const S.x).cast_mut().write(1);  // Writing to an immutable static that's still being initialized!
    },
};

fn main() {
    println!("{}", S.x);
}

I expected to see this happen: An error of some sort, or Miri reports UB.

Instead, this happened: The program compiles and outputs 0. Miri does not detect UB.

Note that writing to a static while initializing a different static is not allowed. For example,

static mut S: i32 = 0;

static T: () = unsafe {
    (&raw mut S).write(1);
};

this produces the following error

error[E0080]: could not evaluate static initializer
    --> src/lib.rs:4:5
     |
4    |     (&raw mut S).write(1);
     |     ^^^^^^^^^^^^^^^^^^^^^ modifying a static's initial value from another static's initializer
     |
note: inside `std::ptr::mut_ptr::<impl *mut i32>::write`
    --> /playground/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mut_ptr.rs:1507:18
     |
1507 |         unsafe { write(self, val) }
     |                  ^^^^^^^^^^^^^^^^
note: inside `std::ptr::write::<i32>`
    --> /playground/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:1580:9
     |
1580 |         intrinsics::write_via_move(dst, src)
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the failure occurred here

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground` (lib) due to 1 previous error

Meta

Reproducible on the playground with 1.89.0-nightly (2025-06-11 e703dff8fe220b78195c)

@rustbot labels +A-const-eval

[theemathas]

Another variant:

#![allow(dead_code)]

struct Foo {
    x: i32,
    y: (),
}

static mut S: Foo = Foo {
    x: 0,
    y: unsafe {
        S.x = 1;
    },
};

fn main() {
    println!("{}", unsafe { S.x });
}

This code compiles and prints 0.

[oli-obk]

Fun. we even have tests for this... but apparently something is not catching it

[oli-obk]

We thought #116564 only made it possible to read from statics while initializing them (which just gives you uninit memory). But looking at the diff a test definitely changed to allow writing to statics, too

[theemathas]

From my testing, reading from a static while initializing it produces a "encountered static that tried to initialize itself with itself" error.

[oli-obk]

oh right, we had to prevent that for zsts as zsts perform no read, so we need to ensure they don't self-initialize

[oli-obk]

Or maybe we said this was fine since the value was always getting overwritten by the finial expression anyway? Because we had no way to allow the final write to the static while forbidding other writes. Slowly some memories of thinking about this before are coming up

[oli-obk]

Ok, yea, this was def intended (#116564 (comment)), although arguably not discussed sufficiently.

I had another look at the impl and it would need a bit of extra interpreter machine logic to prevent (or more specifically to special case _0 = foo MIR assignments to be ok, but all other uses of the static will get an error).

idk, considering

this was fine since the value was always getting overwritten by the finial expression anyway

There's nothing really important to change here. Considering

    let mut data = (0, 0);
    data = (1, {
        data.0 = 5;
        2
    });
    assert_eq!(data, (1, 2));

is fine, I don't see a good argument for rejecting the static equivalent

[Nemo157]

Might be a good candidate for a clippy lint in that case.

[oli-obk]

cc @rust-lang/wg-const-eval

I think this is working as intended, but it is a bit surprising as it's rare that you can refer to the address of something before it is initialized

[RalfJung]

(or more specifically to special case _0 = foo MIR assignments to be ok, but all other uses of the static will get an error)

IMO that is the main point: there's no difference between writing to &raw mut S and writing to _0, we just don't have syntax for the latter. _0 always gets fully overwritten at the end, so these intermediate writes can't even have any effect. But semantically this must already work, so we may as well have it work in all cases.

But ultimately it is up to @rust-lang/lang whether they consider this problematic.

[lcnr]

I feel like I don't have a good tell on this behavior yet. It feels somewhat similar to the following, forbidden code:

#![allow(dead_code)]

struct Foo {
    x: i32,
    y: (),
}

fn main() {
    let s: Foo;
    s = Foo {
        x: 0,
        y: unsafe {
            (&raw const s.x).cast_mut().write(1); // Writing to an immutable static that's still being initialized!
        },
    };
    println!("{}", s.x);
}

If I understand correctly, we do not allow reading from statics in their initializer, i.e. the following errors with "could not evaluate static initializer" https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=47e4a7aebe19fdd8b8c7f4e45fa8fa81:

static S: Foo = Foo {
    x: 0,
    y: unsafe {
        let _ = (&raw const S.x).cast::<()>().read(); 
    },
};

Is the following summary correct:

• reading from statics in statics initializers is required to be non-cyclic. you can't read from the static you're currently initializing
• writing to the (regardless of mutability) static we're currently initializing is allowed and will always get overwritten by the final write to the return place of the initializer

This means while the writes to the static are weird, they do not cause any opsem or soundness issues.

I personally feel like we should forbid these useless writes. Afaict they are always irrelevant and I can't think of a case where it would be desirable. If we only allow initializing the static with the final value of its initializer were trivial to do, do you think we'd still want to support these irrelevant earlier writes?

[oli-obk]

I personally feel like we should forbid these useless writes. Afaict they are always irrelevant and I can't think of a case where it would be desirable. If we only allow initializing the static with the final value of its initializer were trivial to do, do you think we'd still want to support these irrelevant earlier writes?

I don't want to support these irrelevant earlier writes. It's just a bit of extra complexity to prevent them, so we actually need to want to prevent them explicitly and thus take the complexity hit.