Tracking Issue for making ptr offset methods "const fn"

[josephlr]

The feature gate for this is #![feature(const_ptr_offset)]. Miri has been able to handle this for some time. This feature allows code like:

static FOO: u8 = 42;
static PTR1: *const u8 = &FOO as *const u8;
static PTR2: *const u8 = PTR1.wrapping_offset(1);

• The following intrinsic functions will be made const fn:

  • intrinsics::offset
  • intrinsics::arith_offset

• The allows the following *const/*mut methods to be const fn:

  • offset
  • wrapping_offset
  • add/sub
  • wrapping_add/wrapping_sub

• The following methods are not part of this issue:

  • align_offset: See align_offset guarantees #62420
  • offset_from: Tracked as part of Tracking issue for ptr::offset_from (feature: ptr_offset_from) #41079 and Tracking Issue for const offset_from (const_ptr_offset_from) #92980
  • wrapping_offset_from: Not possible across different allocations
  • Any read/write methods: Tracked in [tracking issue] dereferencing raw pointers inside constants (const_raw_ptr_deref) #51911

Steps (based on #69821)

• Implemented in Make pointer offset methods/intrinsics const #71500
• Check if any other core/alloc/std functions should be made const along with this.
• Remove miri's implementations for offset and arith_offset
• Final commenting period (FCP): Tracking Issue for making ptr offset methods "const fn" #71499 (comment)
• Stabilization PR

Unresolved Questions

• How should offset == 0 be handled?
  • As implemented, we allow offsets of 0 for all pointers (including dangling pointers) except for null pointers.
  • Should we allow offsets of 0 for null pointers?
  • The documentation is a bit unclear on this, see: ptr::offset should explicitly clarify 0-sized offset semantics #65108 and @RalfJung's comment

CC: @RalfJung @oli-obk @rust-lang/wg-const-eval

[RalfJung]

Cc @rust-lang/wg-const-eval (unfortunately GH only lets org members ping teams :/ )

Note that Miri already has implementations of the relevant intrinsics but they need to be moved to rustc.

[RalfJung]

One concern with these intrinsics that needs to be resolved before stabilization: for offset/add/sub, we cannot actually check during const-eval if the operation overflows, because that depends on the actual integer address the allocation starts at.