Tracking Issue for const_swap

[usbalbin]

Feature gate: #![feature(const_swap)]

This is a tracking issue for making the functions mem::swap and ptr::swap[_nonoverlapping] and some other swap related functions const fn.

Public API

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

mod mem {
    pub const fn swap<T>(x: &mut T, y: &mut T);
}

impl<T> [T] {
    pub const fn swap(&mut self, a: usize, b: usize);
}

impl<T: ?Sized> *mut T {
    pub const unsafe fn swap(self, with: *mut T);
}

impl <T> NonNull<T> {
    pub const unsafe fn swap(self, with: NonNull<T>);
}

Steps / History

• Implementation (mem and ptr): Constify copy related functions #83091
• Implementation ([T] and *mut T ) Extend the const swap feature #90644
• NonNull methods stabilized, constness moved to this gate Stabilize non_null_convenience #124498
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• What do we do with the bytewise pointer swap situation?

[RalfJung]

This got reverted again by #86003, but hopefully we can re-land it soon.

[RalfJung]

@pnkfelix I don't quite understand why you un-constified swap... it seems write is the underlying source of the problem. Does it not work to add the const stability attribute here?

[usbalbin]

I have reverted the constness reverts in #86295

[est31]

I've filed #90644 to extend the const_swap feature to three more functions. Some of them can panic, but const_panic is stable as of #89508. Edit: seems that std library functions need #90687 on top of const_panic stabilization. I expect that PR gets merged quite soon.

[jhpratt]

This should be blocked on const mut refs, I believe.

[RalfJung]

The following code used to work with swap_nonoverlapping, but doesn't any more:

#![feature(const_swap)]
#![feature(const_mut_refs)]
use std::{
    mem::{self, MaybeUninit},
    ptr,
};

const X: () = {
    let mut ptr1 = &1;
    let mut ptr2 = &2;

    // Swap them, bytewise.
    unsafe {
        ptr::swap_nonoverlapping(
            &mut ptr1 as *mut _ as *mut MaybeUninit<u8>,
            &mut ptr2 as *mut _ as *mut MaybeUninit<u8>,
            mem::size_of::<&i32>(),
        );
    }
    
    // Make sure they still work.
    assert!(*ptr1 == 2);
    assert!(*ptr2 == 1);
};

That is a regression introduced by the new implementation of swap_nonoverlapping in #94212. Though arguably it is a mere coincidence that the previous implementation worked: this is fundamentally caused by a limitation of compile-time evaluation. We have no good way to represent a 'part' of a pointer, so we cannot work on pointers bytewise. Changing the above code to copy a single &i32 rather than 8 MaybeUninit<u8> fixes it.

Not being able to work bytewise on pointer is a general limitation of CTFE, so we could document this as such. However, note that copy and copy_nonoverlapping actually work here; this is because they are implemented via intrinsics which then do copy the entire memory range at once, thus not having to deal with pointers bytewise.

[RalfJung]

So... we could easily stabilize ptr::swap once #129195 lands, but ptr::swap_nonoverlapping has a serious limitation currently where it can fail when the data-to-swap contains pointers that cross the "element boundary" of such a swap. (The key difference here is that ptr::swap_nonoverlapping takes a count parameter, but ptr::swap only ever swaps a single element.)

Fixing this requires either an intrinsic for swapping (maybe only used by const-eval), or using const_heap... we have to allocate enough space to do the 3-copy version of swapping, as the more efficient "progressive" swapping is exactly what causes the problem.

[RalfJung]

Here's the test for this:

#[test]
fn test_const_swap() {
    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);
    };

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

        // Swap ptr1 and ptr2, bytewise. `swap` does not take a count
        // so the best we can do is use an array.
        type T = [u8; mem::size_of::<&i32>()];
        unsafe {
            ptr::swap(
                ptr::from_mut(&mut ptr1).cast::<T>(),
                ptr::from_mut(&mut ptr2).cast::<T>(),
            );
        }

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

[clarfonthey]

Just to comment on this, but swap would be useful to const-stabilise now even if swap_nonoverlapping takes a bit longer, since it would simplify code that has to do a manual 3-way swap a lot.

[RalfJung]

Feel free to make a PR that proposes stabilizing ptr::swap. :)

[joseluis]

After today's 1.83.0 release this is no longer blocked on const_mut_refs .

[RalfJung]

Yeah that has been unblocked on nightly for a while. But it is blocked on the concern mentioned above. EDIT: I updated the PR description to match that.

[RalfJung]

@rust-lang/libs-api I propose that we const-stabilize all of the above mentioned functions except for swap_nonoverlapping. The problem with swap_nonoverlapping is that it takes a count: isize parameter, and is described as an "untyped" operation acting on count * size_of::<T>() bytes, but the const-implementation currently acts count times on chunks of size_of::<T>() bytes, and that is not the same when there is a pointer that is partially contained in multiple chunks, but wholly contained in the entire large range.

ptr::swap has no count parameter, so there is no similar problem there. And all the other methods can be implemented with ptr::swap.

[dtolnay]

@rfcbot fcp merge

• https://doc.rust-lang.org/nightly/core/ptr/fn.swap.html
• https://doc.rust-lang.org/nightly/core/mem/fn.swap.html
• https://doc.rust-lang.org/nightly/core/primitive.slice.html#method.swap
• https://doc.rust-lang.org/nightly/core/primitive.pointer.html#method.swap
• https://doc.rust-lang.org/nightly/core/ptr/struct.NonNull.html#method.swap

Leaving out core::ptr::swap_nonoverlapping for now per the recommendation in #83163 (comment).

Lastly there is <[_]>::swap_unchecked which is still unstable. Let's move its const stability out of this issue to be tracked as part of #88539 instead.

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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.

[RalfJung]

Lastly there is <[_]>::swap_unchecked which is still unstable. Let's move its const stability out of this issue to be tracked as part of #88539 instead.

Oh, good catch, I missed that.

I will file a PR to move swap_unchecked and swap_nonoverlapping to separate feature gates.

EDIT: PR is up at #133669.
As part of that I also created #133668 to cover const swap_nonoverlapping.

[RalfJung]

@Amanieu @BurntSushi @joshtriplett @m-ou-se FCP checkbox reminder. :)
This const-stabilizes some stable fn that could already be (unsafely) implemented in terms of other stable const fn, so it's a fairly straight-forward extension of our const API surface.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.