diff --git a/library/alloc/src/vec/mod.rs b/library/alloc/src/vec/mod.rs
index 941cc0239d2b8..b3e5ecc924071 100644
--- a/library/alloc/src/vec/mod.rs
+++ b/library/alloc/src/vec/mod.rs
@@ -2798,14 +2798,14 @@ impl<T, I: SliceIndex<[T]>, A: Allocator> IndexMut<I> for Vec<T, A> {
 /// depending on the supplied iterator:
 ///
 /// * preallocate based on [`Iterator::size_hint()`]
-///   * and panic if the number of items is not outside the provided lower/upper bounds
+///   * and panic if the number of items is outside the provided lower/upper bounds
 /// * use an amortized growth strategy similar to `pushing` one item at a time
 /// * perform the iteration in-place on the original allocation backing the iterator
 ///
 /// The last case warrants some attention. It is an optimization that in many cases reduces peak memory
 /// consumption and improves cache locality. But when big, short-lived allocations are created,
-/// only a small fraction of their items gets collected, no further use is made of the spare capacity
-/// and the resulting `Vec` is moved into a longer-lived structure this can lead to the large
+/// only a small fraction of their items get collected, no further use is made of the spare capacity
+/// and the resulting `Vec` is moved into a longer-lived structure, then this can lead to the large
 /// allocations having their lifetimes unnecessarily extended which can result in increased memory
 /// footprint.
 ///