Consteval pointer fragment support was not properly disabled.

[theemathas]

In #144081, pointer fragment support was enabled in consteval. Then, a bug was found in #146291, so this support was supposedly then disabled in #146324. However, it seems like this disabling was not done properly.

The below code is adapted from the previously-deleted test in https://github.com/rust-lang/rust/pull/144081/files#diff-7882729ad52694021ddccdd40fefa200d6d24ead1d586852eb4816bce32f2c6b

const PARTIAL_OVERWRITE: () = {
    let mut p = &42;
    unsafe {
        let ptr: *mut _ = &mut p;
        *(ptr as *mut u8) = 123;
    }
};

This code compiles in beta, but gives the following error in stable:

error[E0080]: unable to overwrite parts of a pointer in memory at alloc4
 --> src/lib.rs:5:9
  |
5 |         *(ptr as *mut u8) = 123;
  |         ^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `PARTIAL_OVERWRITE` 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`.

I am unable to reproduce the bug in #146291, but I still find it worrisome that new code was newly allowed seemingly unintentionally.

Is this operation intended to be supported in consteval?

cc @RalfJung

Meta

Tested on the playground with versions 1.91.0-beta.9 (2025-10-17 1f251978870710eb72e9) and 1.90.0

[RalfJung]

I think this is fine; we're basically delaying the partial pointer check until the time the pointer is being read.

Cc @rust-lang/lang @rust-lang/wg-const-eval

[traviscross]

As a lang matter we OKed the original version, so, for my part, I'd say this subset seems OK if we think it isn't affected by the #146291 issue that caused the revert.

Probably, though, we should make that PARTIAL_OVERWRITE ui test live and assert that it passes.

[theemathas]

Does this need a release notes entry?