Vec: avoid creating slices to the elements

[RalfJung]

Instead of self.deref_mut().as_mut_ptr() to get a raw pointer to the buffer, use self.buf.ptr_mut(). This (a) avoids creating a unique reference to all existing elements without any need, and (b) creates a pointer that can actually be used for the entire buffer, and not just for the part of it covered by self.deref_mut().

I also got worried about RawVec::ptr returning a *mut T from an &self, so I added both a mutable and an immutable version.

Cc @gankro in particular for the assume changes -- I don't know why that is not in Unique, but I moved it up from Vec::deref to RawVec::ptr to avoid having to repeat it everywhere.

Fixes #60847

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

There's just too many things using RawVec, I am going to give up on that "better mutability tracking". Not sure if y'all would want that anyway.

[sfackler]

Should this just return a NonNull<T>?

[RalfJung]

Maybe? There might be a reason for why this looks the way it does. Possibly because NonNull is not very ergonomic.

[Gankra]

yeah, NonNull is only useful as a storage type, it's useless for doing actual work.

[hanna-kruppe]

(b) creates a pointer that can actually be used for the entire buffer, and not just for the part of it covered by self.deref_mut().

This seems like it would also be a problem for anyone outside liballoc who uses as_mut_ptr to e.g.

• initialize parts of a vector before calling set_len
• disassemble a vector and later reconstruct it with Vec::from_raw_parts
• keep a cursor into the Vec as its length changes (similar to the test you added, but moving the pointer around, into portions of the buffer that are added later)

Is that right? And the workaround used here (accessing the internal RawVec) isn't available outside liballoc, right?

So perhaps we should add Vec::as_mut_ptr that returns a pointer covering the vector's entire buffer, not just the 0..len portion? (Plus Vec::as_ptr for symmetry, I guess.)

[RalfJung]

Yes that is correct. Vec::as_mut_ptr (via DerefMut) may only be used to access the elements 0..len with len taken at the time of the invocation.

That's what Stacked Borrows says, anyway. ;) This might also be an indication that the model is too strict? The desired interaction with unsized types is not really clear. One custom DST are a thing, I doubt we want Stacked Borrows to run the arbitrary user code to compute the size...

[hanna-kruppe]

Assuming that this restriction on the use of <[T]>::{as_ptr, as_mut_ptr} prevails in some form, what do you think about (rephrasing the last part of my previous comment for clarity) adding inherent methods as_ptr, as_mut_ptr to Vec that shadow the slice methods and differ only in that they return a pointer that may be used to access elements 0..capacity?

[RalfJung]

That sounds very reasonable!

I didn't do that here because I was not sure how that shadowing would work out.

[Gankra]

re: assume: I believe historically we found that llvm gets really overexcited when it finds assumes and wastes waaay too much time trying to profitably use them. So we moved to only inserting them in strategic hotspots, instead of everywhere we could.

[Gankra]

Also I agree with @rkruppe. If as_ptr is a semantic footgun for the implementation, it's a footgun for our users too. We should add the shadowing implementation (which works fine, Vec shadows slice methods in a few places already).

[RalfJung]

I will have to make them insta-stable though to not regress people doing vec.as_mut_ptr(), right?

[RalfJung]

All right, I rewrote this PR to add shadowing methods instead. I also moved the assume there.

[RalfJung]

as_mut_ptr now contains an assume so I think I can remove this? Unfortunately whoever added this did not leave a comment, because it seemed redundant before already.

[sfackler]

r? @gankro

[Gankra]

@bors r+

[bors]

@gankro: 🔑 Insufficient privileges: Not in reviewers

[RalfJung]

@bors r=Gankro

[bors]

📌 Commit 428ab7e has been approved by Gankro