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.

[aodhneine]

Hi, what's the progress on this issue?

[oli-obk]

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.

As decided in the unsafe const RFC, we only need to do a best effort UB check.

I reviewed the methods in question and believe we can stabilize all of them. The only user visible const/runtime differences occur in the presence of UB.

[RalfJung]

Indeed I think there is no reason to wait longer, we can stabilize this. Does someone want to prepare a stabilization PR?

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.