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.)

[traviscross]

...ptr::swap_nonoverlapping is quite useful even with this limitation, and this approach is forward-compatible with lifting the limitation later.

Generally things that take this shape get a warm reception. It sounds fine to me. We'll try to get to this one in the meeting next week.

[nikomatsakis]

If this is a 2-way door (sounds like yes) then I have no objection to stabilizing. I admit I don't 100% understand the details of the question @RalfJung that you are asking though.

[traviscross]

@rustbot labels -I-lang-nominated

We talked about this in the meeting today and had positive vibes. Please nominate for us the stabilization PR and we'll FCP that.

[RalfJung]

@nikomatsakis

Stabilization is never a 2-way door, we cannot un-do a stabilization... so I am confused by the first part of your message.

For the second part, basically I am asking whether it is okay to stabilize a function that sometimes leads to a const-eval failure in a situation where the code doesn't have UB or anything like that -- it's just a situation that is hard to support in const-eval, and our current implementation does not support it. Users can already trigger the same const-eval failure themselves with unsafe code, but this would be the first time that failure can be triggered from safe code. That felt to me like it should get explicit t-lang approval. :)

[joshtriplett]

@RalfJung For the first part, the conclusion was "this doesn't commit us to continuing to fail in this case, we can start handling it in the future".

@nikomatsakis I think you wanted "not closing a one-way door" rather than "is a two-way door". :)

[nikomatsakis]

Let me restate my summary of what is happening to check my understanding:

If I understand, the impl of swap_nonoverlapping can spuriously fail when the two pointers happen to be adjacent in memory (i.e., in the example, there are two local variables and the first array ends at the same address where the second begins), That is not a soundness problem because const in general is allowed to be incomplete with respect to runtime dynamics, but it could cause a bad user experience. It seems like you are basically asking "is it ok to stabilize giving this known bug".

@RalfJung the two-way door I was referring to is: we can fix this impl bug in the future.

[RalfJung]

If I understand, the impl of swap_nonoverlapping can spuriously fail when the two pointers happen to be adjacent in memory

No, it has nothing to do with that. It is always UB to do any kind of access on adjacent allocations.

The swap_nonoverlapping call in the example swaps the contents of ptr1 and ptr2. I don't know which "arrays" you are talking about.

[RalfJung]

I came up with a new version of the example, maybe that makes it more clear. :)
See the comments in the code:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a

Stabilization PR is up at #137280.

[oli-obk]

The issue is that doing a bytewise copy of memory containing pointers will fail as we cannot represent a single byte of a pointer right now.