Skip to content

Commit aea7602

Browse files
authored
Unrolled build for rust-lang#135933
Rollup merge of rust-lang#135933 - hkBst:patch-19, r=workingjubilee Explain how Vec::with_capacity is faithful This is a revival of rust-lang#99790 building on the prose of `@workingjubilee` and edits of `@jmaargh.` Closes rust-lang#99385.
2 parents f5729cf + da7210b commit aea7602

File tree

1 file changed

+17
-5
lines changed

1 file changed

+17
-5
lines changed

library/alloc/src/vec/mod.rs

+17-5
Original file line numberDiff line numberDiff line change
@@ -355,11 +355,20 @@ mod spec_extend;
355355
/// and it may prove desirable to use a non-constant growth factor. Whatever
356356
/// strategy is used will of course guarantee *O*(1) amortized [`push`].
357357
///
358-
/// `vec![x; n]`, `vec![a, b, c, d]`, and
359-
/// [`Vec::with_capacity(n)`][`Vec::with_capacity`], will all produce a `Vec`
360-
/// with at least the requested capacity. If <code>[len] == [capacity]</code>,
361-
/// (as is the case for the [`vec!`] macro), then a `Vec<T>` can be converted to
362-
/// and from a [`Box<[T]>`][owned slice] without reallocating or moving the elements.
358+
/// It is guaranteed, in order to respect the intentions of the programmer, that
359+
/// all of `vec![e_1, e_2, ..., e_n]`, `vec![x; n]`, and [`Vec::with_capacity(n)`] produce a `Vec`
360+
/// that requests an allocation of the exact size needed for precisely `n` elements from the allocator,
361+
/// and no other size (such as, for example: a size rounded up to the nearest power of 2).
362+
/// The allocator will return an allocation that is at least as large as requested, but it may be larger.
363+
///
364+
/// It is guaranteed that the [`Vec::capacity`] method returns a value that is at least the requested capacity
365+
/// and not more than the allocated capacity.
366+
///
367+
/// The method [`Vec::shrink_to_fit`] will attempt to discard excess capacity an allocator has given to a `Vec`.
368+
/// If <code>[len] == [capacity]</code>, then a `Vec<T>` can be converted
369+
/// to and from a [`Box<[T]>`][owned slice] without reallocating or moving the elements.
370+
/// `Vec` exploits this fact as much as reasonable when implementing common conversions
371+
/// such as [`into_boxed_slice`].
363372
///
364373
/// `Vec` will not specifically overwrite any data that is removed from it,
365374
/// but also won't specifically preserve it. Its uninitialized memory is
@@ -383,14 +392,17 @@ mod spec_extend;
383392
/// [`shrink_to`]: Vec::shrink_to
384393
/// [capacity]: Vec::capacity
385394
/// [`capacity`]: Vec::capacity
395+
/// [`Vec::capacity`]: Vec::capacity
386396
/// [mem::size_of::\<T>]: core::mem::size_of
387397
/// [len]: Vec::len
388398
/// [`len`]: Vec::len
389399
/// [`push`]: Vec::push
390400
/// [`insert`]: Vec::insert
391401
/// [`reserve`]: Vec::reserve
402+
/// [`Vec::with_capacity(n)`]: Vec::with_capacity
392403
/// [`MaybeUninit`]: core::mem::MaybeUninit
393404
/// [owned slice]: Box
405+
/// [`into_boxed_slice`]: Vec::into_boxed_slice
394406
#[stable(feature = "rust1", since = "1.0.0")]
395407
#[cfg_attr(not(test), rustc_diagnostic_item = "Vec")]
396408
#[rustc_insignificant_dtor]

0 commit comments

Comments
 (0)