@@ -166,7 +166,7 @@ use super::range::RangeArgument;
166166/// # Slicing
167167///
168168/// A `Vec` can be mutable. Slices, on the other hand, are read-only objects.
169- /// To get a slice, use "&" . Example:
169+ /// To get a slice, use `&` . Example:
170170///
171171/// ```
172172/// fn read_slice(slice: &[usize]) {
@@ -203,33 +203,33 @@ use super::range::RangeArgument;
203203///
204204/// # Guarantees
205205///
206- /// Due to its incredibly fundamental nature, Vec makes a lot of guarantees
206+ /// Due to its incredibly fundamental nature, ` Vec` makes a lot of guarantees
207207/// about its design. This ensures that it's as low-overhead as possible in
208208/// the general case, and can be correctly manipulated in primitive ways
209209/// by unsafe code. Note that these guarantees refer to an unqualified `Vec<T>`.
210210/// If additional type parameters are added (e.g. to support custom allocators),
211211/// overriding their defaults may change the behavior.
212212///
213- /// Most fundamentally, Vec is and always will be a (pointer, capacity, length)
213+ /// Most fundamentally, ` Vec` is and always will be a (pointer, capacity, length)
214214/// triplet. No more, no less. The order of these fields is completely
215215/// unspecified, and you should use the appropriate methods to modify these.
216216/// The pointer will never be null, so this type is null-pointer-optimized.
217217///
218218/// However, the pointer may not actually point to allocated memory. In particular,
219- /// if you construct a Vec with capacity 0 via [`Vec::new()`], [`vec![]`][`vec!`],
219+ /// if you construct a ` Vec` with capacity 0 via [`Vec::new()`], [`vec![]`][`vec!`],
220220/// [`Vec::with_capacity(0)`][`Vec::with_capacity`], or by calling [`shrink_to_fit()`]
221221/// on an empty Vec, it will not allocate memory. Similarly, if you store zero-sized
222222/// types inside a `Vec`, it will not allocate space for them. *Note that in this case
223- /// the `Vec` may not report a [`capacity()`] of 0*. Vec will allocate if and only
223+ /// the `Vec` may not report a [`capacity()`] of 0*. ` Vec` will allocate if and only
224224/// if [`mem::size_of::<T>()`]` * capacity() > 0`. In general, `Vec`'s allocation
225225/// details are subtle enough that it is strongly recommended that you only
226- /// free memory allocated by a Vec by creating a new Vec and dropping it.
226+ /// free memory allocated by a ` Vec` by creating a new ` Vec` and dropping it.
227227///
228228/// If a `Vec` *has* allocated memory, then the memory it points to is on the heap
229229/// (as defined by the allocator Rust is configured to use by default), and its
230230/// pointer points to [`len()`] initialized elements in order (what you would see
231- /// if you coerced it to a slice), followed by `[ capacity()][`capacity ()`] -
232- /// [len()][`len()`]` logically uninitialized elements.
231+ /// if you coerced it to a slice), followed by [` capacity()`]` - `[`len ()`]
232+ /// logically uninitialized elements.
233233///
234234/// `Vec` will never perform a "small optimization" where elements are actually
235235/// stored on the stack for two reasons:
@@ -249,8 +249,8 @@ use super::range::RangeArgument;
249249/// [`shrink_to_fit`][`shrink_to_fit()`].
250250///
251251/// [`push`] and [`insert`] will never (re)allocate if the reported capacity is
252- /// sufficient. [`push`] and [`insert`] *will* (re)allocate if `[len()][`len()`]
253- /// == [capacity()] [`capacity()`]` . That is, the reported capacity is completely
252+ /// sufficient. [`push`] and [`insert`] *will* (re)allocate if
253+ /// [`len()`]` == ` [`capacity()`]. That is, the reported capacity is completely
254254/// accurate, and can be relied on. It can even be used to manually free the memory
255255/// allocated by a `Vec` if desired. Bulk insertion methods *may* reallocate, even
256256/// when not necessary.
@@ -261,11 +261,10 @@ use super::range::RangeArgument;
261261/// strategy is used will of course guarantee `O(1)` amortized [`push`].
262262///
263263/// `vec![x; n]`, `vec![a, b, c, d]`, and
264- /// [`Vec::with_capacity(n)`][`Vec::with_capacity`], will all
265- /// produce a `Vec` with exactly the requested capacity. If `[len()][`len()`] ==
266- /// [capacity()][`capacity()`]`, (as is the case for the [`vec!`] macro), then a
267- /// `Vec<T>` can be converted to and from a [`Box<[T]>`] without reallocating or
268- /// moving the elements.
264+ /// [`Vec::with_capacity(n)`][`Vec::with_capacity`], will all produce a `Vec`
265+ /// with exactly the requested capacity. If [`len()`]` == `[`capacity()`],
266+ /// (as is the case for the [`vec!`] macro), then a `Vec<T>` can be converted to
267+ /// and from a [`Box<[T]>`][owned slice] without reallocating or moving the elements.
269268///
270269/// `Vec` will not specifically overwrite any data that is removed from it,
271270/// but also won't specifically preserve it. Its uninitialized memory is
@@ -292,7 +291,7 @@ use super::range::RangeArgument;
292291/// [`push`]: ../../std/vec/struct.Vec.html#method.push
293292/// [`insert`]: ../../std/vec/struct.Vec.html#method.insert
294293/// [`reserve`]: ../../std/vec/struct.Vec.html#method.reserve
295- /// [`Box<[T]>` ]: ../../std/boxed/struct.Box.html
294+ /// [owned slice ]: ../../std/boxed/struct.Box.html
296295#[ stable( feature = "rust1" , since = "1.0.0" ) ]
297296pub struct Vec < T > {
298297 buf : RawVec < T > ,
@@ -329,9 +328,10 @@ impl<T> Vec<T> {
329328 /// reallocating. If `capacity` is 0, the vector will not allocate.
330329 ///
331330 /// It is important to note that this function does not specify the *length*
332- /// of the returned vector, but only the *capacity*. (For an explanation of
333- /// the difference between length and capacity, see the main `Vec<T>` docs
334- /// above, 'Capacity and reallocation'.)
331+ /// of the returned vector, but only the *capacity*. For an explanation of
332+ /// the difference between length and capacity, see *[Capacity and reallocation]*.
333+ ///
334+ /// [Capacity and reallocation]: #capacity-and-reallocation
335335 ///
336336 /// # Examples
337337 ///
@@ -497,13 +497,13 @@ impl<T> Vec<T> {
497497 self . buf . shrink_to_fit ( self . len ) ;
498498 }
499499
500- /// Converts the vector into [`Box<[T]>`].
500+ /// Converts the vector into [`Box<[T]>`][owned slice] .
501501 ///
502502 /// Note that this will drop any excess capacity. Calling this and
503503 /// converting back to a vector with [`into_vec()`] is equivalent to calling
504504 /// [`shrink_to_fit()`].
505505 ///
506- /// [`Box<[T]>` ]: ../../std/boxed/struct.Box.html
506+ /// [owned slice ]: ../../std/boxed/struct.Box.html
507507 /// [`into_vec()`]: ../../std/primitive.slice.html#method.into_vec
508508 /// [`shrink_to_fit()`]: #method.shrink_to_fit
509509 ///
@@ -779,7 +779,7 @@ impl<T> Vec<T> {
779779
780780 /// Retains only the elements specified by the predicate.
781781 ///
782- /// In other words, remove all elements `e` such that `f(&e)` returns false.
782+ /// In other words, remove all elements `e` such that `f(&e)` returns ` false` .
783783 /// This method operates in place and preserves the order of the retained
784784 /// elements.
785785 ///
0 commit comments