-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vec: avoid creating slices to the elements #61114
Conversation
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There's just too many things using |
684f4a5
to
487a108
Compare
src/liballoc/raw_vec.rs
Outdated
@@ -194,7 +195,9 @@ impl<T, A: Alloc> RawVec<T, A> { | |||
/// Unique::empty() if `cap = 0` or T is zero-sized. In the former case, you must | |||
/// be careful. | |||
pub fn ptr(&self) -> *mut T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this just return a NonNull<T>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe? There might be a reason for why this looks the way it does. Possibly because NonNull
is not very ergonomic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, NonNull is only useful as a storage type, it's useless for doing actual work.
This seems like it would also be a problem for anyone outside liballoc who uses
Is that right? And the workaround used here (accessing the internal RawVec) isn't available outside liballoc, right? So perhaps we should add |
Yes that is correct. 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... |
Assuming that this restriction on the use of |
That sounds very reasonable! I didn't do that here because I was not sure how that shadowing would work out. |
re: |
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). |
I will have to make them insta-stable though to not regress people doing |
All right, I rewrote this PR to add shadowing methods instead. I also moved the |
@@ -1754,7 +1819,6 @@ impl<T> IntoIterator for Vec<T> { | |||
fn into_iter(mut self) -> IntoIter<T> { | |||
unsafe { | |||
let begin = self.as_mut_ptr(); | |||
assume(!begin.is_null()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
r? @gankro |
@bors r+ |
@gankro: 🔑 Insufficient privileges: Not in reviewers |
@bors r=Gankro |
📌 Commit 428ab7e has been approved by |
Vec: avoid creating slices to the elements 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 rust-lang#60847
Vec: avoid creating slices to the elements 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 rust-lang#60847
Rollup of 9 pull requests Successful merges: - #61087 (Tweak `self` arg not as first argument of a method diagnostic) - #61114 (Vec: avoid creating slices to the elements) - #61144 (Suggest borrowing for loop head on move error) - #61149 (Fix spelling in release notes) - #61161 (MaybeUninit doctest: remove unnecessary type ascription) - #61173 (Auto-derive Encode and Decode implementations of DefPathTable) - #61184 (Add additional trace statements to the const propagator) - #61189 (Turn turbo 🐟 🍨 into an error) - #61193 (Add comment to explain why we change the layout for Projection) Failed merges: r? @ghost
Before, they went through `&str` and `&mut str`, which created intermediary references, shrinking provenance to only the initialized parts. `Vec<T>` already has such inherent methods added in rust-lang#61114.
Instead of
self.deref_mut().as_mut_ptr()
to get a raw pointer to the buffer, useself.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 byself.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 inUnique
, but I moved it up fromVec::deref
toRawVec::ptr
to avoid having to repeat it everywhere.Fixes #60847