Skip to content

Make explicit guarantees about Vec’s allocator #145260

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 61 additions & 11 deletions library/alloc/src/vec/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,27 @@
//! v[1] = v[1] + 5;
//! ```
//!
//! # Memory layout
//!
//! When the type is non-zero-sized and the capacity is nonzero, [`Vec`] uses the [`Global`]
//! allocator for its allocation. It is valid to convert both ways between such a [`Vec`] and a raw
//! pointer allocated with the [`Global`] allocator, provided that the [`Layout`] used with the
//! allocator is correct for a sequence of `capacity` elements of the type, and the first `len`
//! values pointed to by the raw pointer are valid. More precisely, a `ptr: *mut T` that has been
//! allocated with the [`Global`] allocator with [`Layout::array::<T>(capacity)`][Layout::array] may
//! be converted into a vec using
//! [`Vec::<T>::from_raw_parts(ptr, len, capacity)`](Vec::from_raw_parts). Conversely, the memory
//! backing a `value: *mut T` obtained from [`Vec::<T>::as_mut_ptr`] may be deallocated using the
//! [`Global`] allocator with the same layout.
//!
//! For zero-sized types (ZSTs), or when the capacity is zero, the `Vec` pointer must be non-null
//! and sufficiently aligned. The recommended way to build a `Vec` of ZSTs if [`vec!`] cannot be
//! used is to use [`ptr::NonNull::dangling`].
//!
//! [`push`]: Vec::push
//! [`ptr::NonNull::dangling`]: NonNull::dangling
//! [`Layout`]: crate::alloc::Layout
//! [Layout::array]: crate::alloc::Layout::array
#![stable(feature = "rust1", since = "1.0.0")]

Expand Down Expand Up @@ -523,18 +543,23 @@ impl<T> Vec<T> {
/// This is highly unsafe, due to the number of invariants that aren't
/// checked:
///
/// * `ptr` must have been allocated using the global allocator, such as via
/// the [`alloc::alloc`] function.
/// * `T` needs to have the same alignment as what `ptr` was allocated with.
/// * If `T` is not a zero-sized type and the capacity is nonzero, `ptr` must have
/// been allocated using the global allocator, such as via the [`alloc::alloc`]
/// function. If `T` is a zero-sized type or the capacity is zero, `ptr` need
/// only be non-null and aligned.
/// * `T` needs to have the same alignment as what `ptr` was allocated with,
/// if the pointer is required to be allocated.
/// (`T` having a less strict alignment is not sufficient, the alignment really
/// needs to be equal to satisfy the [`dealloc`] requirement that memory must be
/// allocated and deallocated with the same layout.)
/// * The size of `T` times the `capacity` (ie. the allocated size in bytes) needs
/// to be the same size as the pointer was allocated with. (Because similar to
/// alignment, [`dealloc`] must be called with the same layout `size`.)
/// * The size of `T` times the `capacity` (ie. the allocated size in bytes), if
/// nonzero, needs to be the same size as the pointer was allocated with.
/// (Because similar to alignment, [`dealloc`] must be called with the same
/// layout `size`.)
/// * `length` needs to be less than or equal to `capacity`.
/// * The first `length` values must be properly initialized values of type `T`.
/// * `capacity` needs to be the capacity that the pointer was allocated with.
/// * `capacity` needs to be the capacity that the pointer was allocated with,
/// if the pointer is required to be allocated.
/// * The allocated size in bytes must be no larger than `isize::MAX`.
/// See the safety documentation of [`pointer::offset`].
///
Expand Down Expand Up @@ -770,12 +795,16 @@ impl<T> Vec<T> {
/// order as the arguments to [`from_raw_parts`].
///
/// After calling this function, the caller is responsible for the
/// memory previously managed by the `Vec`. The only way to do
/// this is to convert the raw pointer, length, and capacity back
/// into a `Vec` with the [`from_raw_parts`] function, allowing
/// the destructor to perform the cleanup.
/// memory previously managed by the `Vec`. Most often, one does
/// this by converting the raw pointer, length, and capacity back
/// into a `Vec` with the [`from_raw_parts`] function; more generally,
/// if `T` is non-zero-sized and the capacity is nonzero, one may use
/// any method that calls [`dealloc`] with a layout of
/// `Layout::array::<T>(capacity)`; if `T` is zero-sized or the
/// capacity is zero, nothing needs to be done.
///
/// [`from_raw_parts`]: Vec::from_raw_parts
/// [`dealloc`]: crate::alloc::GlobalAlloc::dealloc
///
/// # Examples
///
Expand Down Expand Up @@ -1755,6 +1784,12 @@ impl<T, A: Allocator> Vec<T, A> {
/// may still invalidate this pointer.
/// See the second example below for how this guarantee can be used.
///
/// The method also guarantees that, as long as `T` is not zero-sized and the capacity is
/// nonzero, the pointer may be passed into [`dealloc`] with a layout of
/// `Layout::array::<T>(capacity)` in order to deallocate the backing memory. If this is done,
/// be careful not to run the destructor of the `Vec`, as dropping it will result in
/// double-frees. Wrapping the `Vec` in a [`ManuallyDrop`] is the typical way to achieve this.
///
/// # Examples
///
/// ```
Expand Down Expand Up @@ -1787,9 +1822,24 @@ impl<T, A: Allocator> Vec<T, A> {
/// }
/// ```
///
/// Deallocating a vector using [`Box`] (which uses [`dealloc`] internally):
///
/// ```
/// use std::mem::{ManuallyDrop, MaybeUninit};
///
/// let mut v = ManuallyDrop::new(vec![0, 1, 2]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it'd be a better example to use types that are Drop and run drop_in_place with the right amount of data before deallocating. Otherwise one would cause leaks by following this pattern.

/// let ptr = v.as_mut_ptr();
/// let capacity = v.capacity();
/// let slice_ptr: *mut [MaybeUninit<i32>] =
/// std::ptr::slice_from_raw_parts_mut(ptr.cast(), capacity);
/// drop(unsafe { Box::from_raw(slice_ptr) });
/// ```
///
/// [`as_mut_ptr`]: Vec::as_mut_ptr
/// [`as_ptr`]: Vec::as_ptr
/// [`as_non_null`]: Vec::as_non_null
/// [`dealloc`]: crate::alloc::GlobalAlloc::dealloc
/// [`ManuallyDrop`]: core::mem::ManuallyDrop
#[stable(feature = "vec_as_ptr", since = "1.37.0")]
#[rustc_const_stable(feature = "const_vec_string_slice", since = "1.87.0")]
#[rustc_never_returns_null_ptr]
Expand Down
Loading