add wrapping_offset_from which allows wrapping but still requires ptrs to be for the same allocation #112837
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri The Miri subtree was changed cc @rust-lang/miri |
RalfJung
force-pushed
the
wrapping_offset_from
branch
2 times, most recently
from
461bb15
to
7428cc4
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
wrapping_offset_from
branch
from
7428cc4
to
663ef24
Compare
This comment has been minimized.
This comment has been minimized.
…s to be for the same allocation
RalfJung
force-pushed
the
wrapping_offset_from
branch
from
663ef24
to
c49d0aa
Compare
| #[unstable(feature = "ptr_wrapping_offset_from", issue = "none")] | ||
| #[rustc_const_unstable(feature = "ptr_wrapping_offset_from", issue = "none")] |
There was a problem hiding this comment.
This could be tracked with wrapping_offset_from or with the other bytes methods, not sure which is more appropriate.
| #[inline] | ||
| #[cfg_attr(miri, track_caller)] // even without panics, this helps for Miri backtraces | ||
| #[cfg(not(bootstrap))] | ||
| pub const unsafe fn wrapping_offset_from(self, origin: *const T) -> isize |
There was a problem hiding this comment.
We could also have a wrapping_sub_ptr, if there is interest.
the8472
added
T-libs-api
|
r=me, but I think this will need a libs-api ACP. @rustbot author |
rustbot
added
S-waiting-on-author
|
This strikes me as more of a lang thing, since it is a new intrinsic?
|
|
Hm, I guess - there is new unstable API though outside of just the intrinsic... |
Mark-Simulacrum
added
the
I-lang-nominated
|
ACP filed at rust-lang/libs-team#244. Cc @rust-lang/wg-const-eval since this proposes a new |
RalfJung
added
T-lang
|
☔ The latest upstream changes (presumably #113377) made this pull request unmergeable. Please resolve the merge conflicts. |
|
The t-libs ACP got rejected for lack of motivation. I don't really have any way to refute that, so I'll close the PR -- if someone has a motivation that requires this function, please let me know. :) |
…jubilee offset_from: docs improvements This is the part of rust-lang#112837 that doesn't add a new function, just tweaks the existing docs.
offset_from: docs improvements This is the part of rust-lang/rust#112837 that doesn't add a new function, just tweaks the existing docs.
Fixes #92512: currently, we have
wrapping_offsetas aconst fn, but there is no way insideconstto perform a subtraction that would tell how much a pointer has been wrapping-offset. This is an unfortunate lack of symmetry, and an issue for some approaches to implementing slice iterators -- those tend to handle zero-sized types by doingwrapping_offsetand then they need awrapping_offset_fromto compute the remaining length of the iterator.So I propose we add a new
wrapping_offset_fromthat is able to always invertwrapping_offset:wrapping_offset_fromis valid if and only iforigincould have been produced fromselfviawrapping_offset. Correspondingly, the requirement for both pointers to be derived from the same allocated object remains (it is also required to make the functionconst), as does the requirement of being an exact multiple (hoping that it aids LLVM in its codegen).byte_wrapping_offset_fromcan be used in case the exact-multiple requirement might be violated.