-
-
Notifications
You must be signed in to change notification settings - Fork 540
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
feat(allocator/vec): remove ManuallyDrop
wrapper
#9742
feat(allocator/vec): remove ManuallyDrop
wrapper
#9742
Conversation
CodSpeed Performance ReportMerging #9742 will not alter performanceComparing Summary
|
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.
Apart from the 2 comments below, this looks good.
We definitely need to keep the const { Self::ASSERT_T_IS_NOT_DROP }
assertions. Vec
itself is non-drop, but these assertions also make sure that T
(what you put in the Vec
) is also non-drop.
This prevents memory leaks because otherwise there'd be nothing stopping you creating, for example, a Vec<'a, std::string::String>
.
{
let mut vec = Vec::new_in(&allocator);
vec.push("foobar".to_string());
// `vec` gets dropped here, but `Vec` doesn't implement `Drop`,
// so it doesn't drop the `String`.
// The 6 bytes of heap memory owned by the `String` is not reclaimed = memory leak.
}
const { Self::ASSERT_T_IS_NOT_DROP }
is a compile-time check which prevents this. The example above will refuse to compile due to this assertion.
e5a1a8e
to
d1e11c1
Compare
a202e87
to
fbba78c
Compare
d1e11c1
to
7403cdf
Compare
7403cdf
to
3812849
Compare
fbba78c
to
32f8347
Compare
3812849
to
cc06e07
Compare
32f8347
to
dda7025
Compare
Merge activity
|
Partially revert #6623, It still keeps the check for non-`drop` element of `Vec`
cc06e07
to
caa477c
Compare
self.reserve(1)
calls with self.grow_one()
for better efficiency
#9856
Partially revert #6623, It still keeps the check for non-
drop
element ofVec