Full support for pointer fragments #72
Comments
4 tasks
This was referenced Feb 19, 2025
tgross35
added a commit
to tgross35/rust
that referenced
this issue
May 4, 2025
…, r=lcnr stabilize ptr::swap_nonoverlapping in const Closes rust-lang#133668 The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on rust-lang/const-eval#72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :) Here's a version of the problematic example to play around with: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 5, 2025
Rollup merge of rust-lang#137280 - RalfJung:const_swap_nonoverlapping, r=lcnr stabilize ptr::swap_nonoverlapping in const Closes rust-lang#133668 The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on rust-lang/const-eval#72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :) Here's a version of the problematic example to play around with: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
github-actions bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this issue
May 5, 2025
stabilize ptr::swap_nonoverlapping in const Closes rust-lang/rust#133668 The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on rust-lang/const-eval#72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :) Here's a version of the problematic example to play around with: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
These days, values of types like
MaybeUninitare only ever represented in-memory in the interpreter; they cannot be stored in aScalar. Only integers (that never have provenance) and pointers (that always have a single well-defined provenance) can exist asScalar.This does give us a chance to represent "partial pointers", so that we could support people writing their own
memcpyin const that works by copyingMaybeUninit<u8>in a loop. I don't know if there's any real usecase for this, but it seems neat. :DThe main challenge is that we have to ensure that when the bytes of a pointer get put back together, that they all appear in the right order. This is not a constraint that our current per-byte provenance system supports, and I doubt that we want to put such a constraint onto regular runtime semantics. We'd also have to report an error if such a pointer fragment byte makes it into the final value of a constant, since AFAIK we can't represent them in LLVM.
The text was updated successfully, but these errors were encountered: