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 > 0 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? 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.) Operations that read/write a part of a pointer generally don't work in const-eval. For ptr::copy and ptr::copy_nonoverlapping we made it work even when a pointer is spread across multiple of the "chunks" being copied, but doing the same for ptr::swap_nonoverlapping is tricky since we would have to allocate some temporary storage somewhere to hold the data from one side while the other side is being copied over.

The other option would be to add full support for "pointer fragments" to const-eval, so that parts a pointer can indeed be copied around and reassambled to a fully usable pointer. That's more attractive honestly (solving the problem properly rather than papering over it with a special-case intrinsic), but also is even more work and risks slowing down the common case where we don't have such pointer fragments. (See rust-lang/const-eval#72.)