Pointer to static is not `guaranteed_eq` to itself.

[theemathas]

I tried this code:

#![feature(const_raw_ptr_comparison)]

static X: u64 = 1;
const B: Option<bool> = (&raw const X).guaranteed_eq(&raw const X);

fn main() {
    println!("{B:?}");
}

I expected to the code to output Some(true), but it output None.

guaranteed_eq is documented to sometimes output None on equal pointers though, so I'm not sure if this is a bug.

@rustbot labels +A-const-eval

Tracking issue: #53020

Meta

Reproducible on the playground with version 1.90.0-nightly (2025-07-27 f8e355c230c6eb7b78ff)

[zachs18]

Seems like there's a FIXME in the compiler for this:

rust/compiler/rustc_const_eval/src/const_eval/machine.rs

Lines 292 to 298 in 9ba00e0

	// FIXME: return a `1` for when both sides are the same pointer, *except* that
	// some things (like functions and vtables) do not have stable addresses
	// so we need to be careful around them (see e.g. #73722).
	// FIXME: return `0` for at least some comparisons where we can reliably
	// determine the result of runtime inequality tests at compile-time.
	// Examples include comparison of addresses in different static items.
	(Scalar::Ptr(..), Scalar::Ptr(..)) => 2,

[xonx4l]

This is not a bug but expected behavior based on how Rust evaluates const expressions. The compiler cannot guarantee that two pointers to the same static are equal at compile time, so guaranteed_eq correctly returns None.

[asquared31415]

by definition, taking the address of a static is guaranteed to produce the same pointer every time. the current behavior is just a limitation of the current implementation, not an inherent property of constant evaluation.

However, properly tracking this is likely very hard and the function must be conservative, so right now only comparisons with null can possibly return a value in const eval, and even then only sometimes.