Tracking Issue for const_swap_nonoverlapping

[RalfJung]

Feature gate: #![feature(const_swap_nonoverlapping)]

This is a tracking issue for making swap_nonoverlapping a const fn.

Public API

mod ptr {
    pub const unsafe fn swap_nonoverlapping<T>(x: *mut T, y: *mut T, count: usize);
}

Steps / History

• Split out of Tracking Issue for const_swap #83163
• Resolve blocking issues
• Final comment period (FCP)¹
• Stabilization PR

Blocking Issues

ptr::swap_nonoverlapping has a limitation currently where it can fail when the data-to-swap contains pointers that cross the "element boundary" of such a swap (i.e., count > 1 and the pointer straddles the boundary between two T). Here's an example of code that unexpectedly fails:

    const {
        let mut ptr1 = &1;
        let mut ptr2 = &666;

        // Swap ptr1 and ptr2, bytewise.
        unsafe {
            ptr::swap_nonoverlapping(
                ptr::from_mut(&mut ptr1).cast::<u8>(),
                ptr::from_mut(&mut ptr2).cast::<u8>(),
                mem::size_of::<&i32>(),
            );
        }

        // Make sure they still work.
        assert!(*ptr1 == 666);
        assert!(*ptr2 == 1);
    };

The proper way to fix this is to implement rust-lang/const-eval#72.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[RalfJung]

I guess the alternative is that we could just error when there is a pointer straddling the boundary of one of the to-be-swapped chunks. That is what happens today, and it doesn't seem entirely unreasonable? This is probably a very rare situation, after all.

@rust-lang/wg-const-eval @rust-lang/lang @rust-lang/opsem do you think it is acceptable for the example code above to error? The context here is that operations that read/write a part of a pointer generally don't work in const-eval. ptr::swap_nonoverlapping is implemented by swapping count many individual chunks of size size_of::<T>() in a loop, so if a pointer straddles the boundary between two such chunks, we get a "trying to read part of a pointer" error.

See here for what the error looks like, and here for a variant of the code that does work since the pointer is entirely contained within a single chunk. (The type used for the chunk does not matter, only its size is relevant.)

We could beef up const-eval so that it can support this kind of code (see rust-lang/const-eval#72), but doing so is non-trivial. ptr::swap_nonoverlapping is quite useful even with this limitation, and this approach is forward-compatible with lifting the limitation later.

[lcnr]

I guess the alternative is that we could just error when there is a pointer straddling the boundary of one of the to-be-swapped chunks. That is what happens today, and it doesn't seem entirely unreasonable? This is probably a very rare situation, after all.

I personally think that as these errors are unrecoverable (i.e. I would be hesitant if ctfe were able to silently fail during candidate selection with const generics) then erroring in this case for now seems totally acceptable for me, especially if it unblocks an otherwise useful function. Adding pointer fragments in the future would be backwards compatible afaict

[RalfJung]

Yeah this behaves like other dynamically detected "const cannot do this" errors, such as is_null on a pointer where we don't know whether it is null or not. And indeed it should be backwards comaptible to make previously failing const expressions work; we generally rely on that for other things like #133700 as well.

[RalfJung]

@rust-lang/lang any comment on this? This is the last raw pointer function that is #[stable] but #[rustc_const_unstable], would be nice to stabilize it and thus finish the task of making all basic raw pointer ops that we can support available in const. :)

[joshtriplett]

@RalfJung Wearing a lang hat but not speaking for the rest of the lang team:

• I do think this should work eventually, and would not be in support of treating this as a permanent limitation.
• No objections to temporarily having such a limitation, and documenting it (in the comments of such functions and possibly in some central documentation of const eval limitations) as "this limitation may be lifted in the future". This is not a one-way door, code is not going to rely on this limitation, and working in many-but-not-all cases is better than working in zero cases. (That's particularly true for const evaluation, in which any error will arise at compile time; such limitations can be more surprising if they occur at runtime.)