On Windows a `static` address changes when copied into another `static` across a module boundary

[Alexendoo]

Technically not the address of the static itself, but it is a confusing interaction

I tried this code:

mod m {
    pub static IN_MOD: &str = &"s";
    pub static IN_MOD_2: &str = IN_MOD;
}

static OUTSIDE: &str = m::IN_MOD;

fn main() {
    println!("{:p}", m::IN_MOD);
    println!("{:p}", m::IN_MOD_2);
    println!("{:p}", OUTSIDE);
}

I expected to see this happen:

The same address printed 3 times as it is on Linux

Instead, this happened:

0x7ff6dba2a370
0x7ff6dba2a370
0x7ff6dba2a3c8

In --release mode the three addresses are the same

Meta

Stable behaves the same

rustc --version --verbose:

rustc 1.81.0-nightly (35b658fb1 2024-07-08)
binary: rustc
commit-hash: 35b658fb1071d752d092751d9f17a9fa7b154ec4
commit-date: 2024-07-08
host: x86_64-pc-windows-msvc
release: 1.81.0-nightly
LLVM version: 18.1.7

[workingjubilee]

...that's so weird I'm not even entirely sure it's a bug.

[bjorn3]

cc @RalfJung

[RalfJung]

Cc @oli-obk

[RalfJung]

But also since we fixed this for Linux, I assume there's some specific Windows interaction here. And all I know about linking on Windows is that it is a lot more complicated than on Linux, and I already don't really understand linking on Linux...

Cc @ChrisDenton @mati865

[oli-obk]

Not sure we're protecting against this on linux either. It just works by accident. the address of string literals is not stable. this won't be an issue on windows either if you use [u8] and let x = [42]; &x for IN_MOD's initializer, as that creates an anonymous nested static

[RalfJung]

Ah the nested static stuff doesn't fire for string literals?

Makes sense. In that case this is not-a-bug. If the issue also crops up without the use of string/byte literals, that would be a different case.

[Alexendoo]

It also occurs with structs:

struct Foo {
    a: usize,
}

mod m {
    pub static IN_MOD: &super::Foo = &super::Foo { a: 1 };
    pub static IN_MOD_2: &super::Foo = IN_MOD;
}

static OUTSIDE: &Foo = m::IN_MOD;

fn main() {
    println!("{:p}", m::IN_MOD);
    println!("{:p}", m::IN_MOD_2);
    println!("{:p}", OUTSIDE);
}
// 0x7ff6916da398
// 0x7ff6916da398
// 0x7ff6916da360

I originally ran into this with declare_lint as it produces a &'static Lint, it's why there's this workaround in Clippy

rust/src/tools/clippy/clippy_lints/src/lib.rs

Lines 482 to 483 in 0fdfb61

	/// Double reference to maintain pointer equality
	lint: &'static &'static Lint,

[RalfJung]

Yeah &super::Foo { a: 1 } is implicitly promoted here. The intended way to write this is

mod m {
    pub static FOO: super::Foo = super::Foo { a: 1 };
    pub static IN_MOD: &super::Foo = &FOO;
    pub static IN_MOD_2: &super::Foo = IN_MOD;
}

[oli-obk]

or

mod m {
    pub static IN_MOD: &super::Foo = {
        let x = super::Foo { a: 1 };
        &x
    };
}

[Alexendoo]

The let version gives a lifetime error

Regarding promotion am I right in thinking that

    pub static IN_MOD: &super::Foo = &super::Foo { a: 1 };

turns into something like the following?

    pub static IN_MOD: &super::Foo = {
        const PROMOTED: super::Foo = super::Foo { a: 1 };
        &PROMOTED
    };

[oli-obk]

oopos, need to use &{x} to move out of the x 💀

[RalfJung]

turns into something like the following?

AFAIK it's more like

    pub static IN_MOD: &super::Foo = {
        const PROMOTED: &super::Foo = &super::Foo { a: 1 };
        PROMOTED
    };

References in constants have no pointer identity guarantees.

Ofc that does not explain how the const itself is accepted so maybe it should be

const PROMOTED: &super::Foo = &const { super::Foo { a: 1 } };

But it's hard to express this entirely syntactically. @oli-obk do we have a MIR body for the pointed-to think or only the reference? I thought it was only for the reference.