stabilize ptr_offset_from

[RalfJung]

This stabilizes ptr::offset_from, and closes #41079. It also removes the deprecated wrapping_offset_from. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API.

Regarding the open questions in #41079:

• Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive.
• Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later.

Also nominating the lang team because this exposes an intrinsic.

The stabilized method is best described by its doc-comment. The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that Miri already implements and that, should LLVM ever obtain a psub operation to subtract pointers, will likely be required for that operation (following the semantics in this paper).

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[Amanieu]

@rfcbot fcp merge

[rfcbot]

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

• @Amanieu
• @SimonSapin
• @cramertj
• @dtolnay
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

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.

[scottmcm]

Also nominating the lang team because this exposes an intrinsic.

This used to just be implemented with normal code, IIRC. Is there some observable semantics that the intrinsic provides? Or is it just for optimization/miri convenience?

[RalfJung]

Hm... so in terms of const-eval, there is definitely something observable, as the implementation with normal code just does not work. (CTFE stops when you try to subtract integers that were obtained from pointers, as this is not an operation we can support in general.)

But you are right that the part that is being stabilized here could actually be implemented (possibly less efficiently) without the intrinsic. I had not thought of that.

[nikomatsakis]

Removing nomination since we discussed in today's @rust-lang/lang meeting. No concerns were raised.

[nikomatsakis]

cc @cramertj @pnkfelix @withoutboats @sfackler for remaining checkboxes :)

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

cc @pnkfelix @cramertj and @sfackler for check-boxes on this issue

[bors]

💔 Test failed - checks-actions

[RalfJung]

The wrapping_offset_from feature was conditionally enabled on SGX, but from what I can see was actually unused.

@bors r=oli-obk

[bors]

📌 Commit 74a860bf2693b58b8058ba371dc93ade6b3810cc has been approved by oli-obk

[cuviper]

The stable versions should be 1.47, unless you're planning a really quick beta backport...

[oli-obk]

@bors r-

[oli-obk]

also needs another rustfmt run

[scottmcm]

One other thing that came to mind:

The safety requirement is currently that the pointers differ by a multiple of the size of T. And interestingly there's no requirement that the pointers actually be aligned.

That's no a soundness gap -- the current implementation doesn't depend on the pointers being aligned -- but it made me wonder if it should be more constrained than it currently is.

[RalfJung]

The stable versions should be 1.47, unless you're planning a really quick beta backport...

Good point. This also means it should land before Tuesday or it'll be 1.48 instead.

[RalfJung]

That's no a soundness gap -- the current implementation doesn't depend on the pointers being aligned -- but it made me wonder if it should be more constrained than it currently is.

In that case however we'd also need a version of this function that works with unaligned pointers. And I cannot imagine how pointers being aligned helps here. Can you?

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit 4129e07 has been approved by oli-obk

[bors]

⌛ Testing commit 4129e07 with merge 9d606d9...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing 9d606d9 to master...

[scottmcm]

@RalfJung No, I don't think I can come up with a reason. And I guess with ptr::raw! and friends coming along unaligned-but-separated pointers are plausible.

All good as-is, then.