Transmuting fn pointer to a usize in const somehow causes UB?

[theemathas]

I tried this code:

fn foo() {}

const _: &usize = unsafe { &std::mem::transmute(foo as fn()) };

I expected to see this happen: Either a normal compile error before consteval, a normal consteval error, or the program successfully compiles.

Instead, this happened:

error[E0080]: constructing invalid value at .<deref>: encountered a pointer, but expected an integer
 --> src/lib.rs:3:1
  |
3 | const _: &usize = unsafe { &std::mem::transmute(foo as fn()) };
  | ^^^^^^^^^^^^^^^ it is undefined behavior to use this value
  |
  = help: this code performed an operation that depends on the underlying bytes representing a pointer
  = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported
  = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
  = note: the raw bytes of the constant (size: 8, align: 8) {
              ╾─────alloc4<imm>─────╼                         │ ╾──────╼
          }

note: erroneous constant encountered
 --> src/lib.rs:3:28
  |
3 | const _: &usize = unsafe { &std::mem::transmute(foo as fn()) };
  |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

I find it rather strange that adding a reference would cause this code to be undefined behavior. For comparison, the following code produces a normal consteval error.

fn foo() {}

const _: usize = unsafe { std::mem::transmute(foo as fn()) };

error[E0080]: unable to turn pointer into integer
 --> src/lib.rs:3:1
  |
3 | const _: usize = unsafe { std::mem::transmute(foo as fn()) };
  | ^^^^^^^^^^^^^^ evaluation of constant value failed here
  |
  = help: this code performed an operation that depends on the underlying bytes representing a pointer
  = help: the absolute address of a pointer is not known at compile-time, so such operations are not supported

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-08 6ccd4476036edfce364e)

[Noratrieb]

Trying to observe the addresses of values in const is undefined behavior. The same happens if you transmute a data pointer to an integer.

[saethlin]

The problem here isn't whether or not the unsafe code is valid, the problem is the change in the diagnostic. The code is disallowed in both cases for the same reason, but something weird is happening, probably related to the required promotion that is causing the diagnostic to change.

[oli-obk]

Ah, so the issue is that the promoted is actually the entire &... expression, not the thing after the &. So evaluation sees

_1: usize = move _2 as usize (Transmute);
_0: &usize = &_1;

The example without the promotion just sees

_0: usize = move _2 as usize (Transmute);

Both of these snippets behave exactly the same (no error, as we don't validate in CTFE like we do in miri). One important detail is that we notice that the layouts are not compatible on transmutes, so we actually force the target local (_1 in the first example, _0 in the second) to become an Allocation instead of staying an Immediate representation.

Then, when the stack frame is popped and the _0 local is copied out into the actual return place:

Because the _0 local is an Allocation, but now the layouts are compatible, we perform a scalar read to turn the value back into a scalar, producing the unable to turn pointer into integer error in the second case. The first case is just a pointer being copied from &usize type to &usize type and everything is fine, the problematic thing is behind the reference.

Later validation explodes.

[RalfJung]

The problem here isn't whether or not the unsafe code is valid, the problem is the change in the diagnostic. The code is disallowed in both cases for the same reason, but something weird is happening, probably related to the required promotion that is causing the diagnostic to change.

Nah, nothing weird, we just use different wording for errors during evaluation vs errors from the post-eval validation. If that's confusing we should align the wording better.