Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid

[saethlin]

I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that as_mut_ptr_range does. (Thanks @RalfJung for the guidance and clearing things up)

I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test vec::test_extend_from_within.

I minimized the test failure into this program:

#![feature(vec_split_at_spare)]
fn main() {
    Vec::<i32>::with_capacity(1).split_at_spare_mut();
}

The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

cc @RalfJung

[RalfJung]

LGTM, but I'll wait on libs team judgment on whether they want to land this (since it only is a fix wrt a proposed model, not wrt anything "official").

[saethlin]

r? @the8472

[the8472]

Note that I'm libs-contributor, not libs-team. That said I'm fairly familiar with Vec so I'll go ahead anyway.

Looking at the history this was intentionally (but tangentially) changed in #82564 and reviewed by @RalfJung. Since that PR was about changing spare_capacity_mut undoing the split_at_spare_mut changes should be fine.

And since Vec uses raw pointers all over the place and it's consistent with changes previously made I don't see an issue with doing it here too.

[the8472]

@bors r=the8472,ralfjung rollup=always

[bors]

📌 Commit 777c853 has been approved by the8472