Auto merge of #27998 - birkenfeld:patch-1, r=alexcrichton

These have been removed and should not be documented here.

Should the replacement crates on crates.io be linked to, or is that not wanted in the core docs?

Author: bors

src/libstd/collections/mod.rs

@@ -25,9 +25,9 @@
 //!
 //! Rust's collections can be grouped into four major categories:
 //!
-//! * Sequences: `Vec`, `VecDeque`, `LinkedList`, `BitVec`
-//! * Maps: `HashMap`, `BTreeMap`, `VecMap`
-//! * Sets: `HashSet`, `BTreeSet`, `BitSet`
+//! * Sequences: `Vec`, `VecDeque`, `LinkedList`
+//! * Maps: `HashMap`, `BTreeMap`
+//! * Sets: `HashSet`, `BTreeSet`
 //! * Misc: `BinaryHeap`
 //!
 //! # When Should You Use Which Collection?
@@ -70,22 +70,11 @@
 //! * You want to be able to get all of the entries in order on-demand.
 //! * You want a sorted map.
 //!
-//! ### Use a `VecMap` when:
-//! * You want a `HashMap` but with known to be small `usize` keys.
-//! * You want a `BTreeMap`, but with known to be small `usize` keys.
-//!
 //! ### Use the `Set` variant of any of these `Map`s when:
 //! * You just want to remember which keys you've seen.
 //! * There is no meaningful value to associate with your keys.
 //! * You just want a set.
 //!
-//! ### Use a `BitVec` when:
-//! * You want to store an unbounded number of booleans in a small space.
-//! * You want a bit vector.
-//!
-//! ### Use a `BitSet` when:
-//! * You want a `BitVec`, but want `Set` properties
-//!
 //! ### Use a `BinaryHeap` when:
 //!
 //! * You want to store a bunch of elements, but only ever want to process the
@@ -123,31 +112,20 @@
 //! | Vec          | O(1)           | O(n-i)*         | O(n-i)         | O(m)*  | O(n-i)         |
 //! | VecDeque     | O(1)           | O(min(i, n-i))* | O(min(i, n-i)) | O(m)*  | O(min(i, n-i)) |
 //! | LinkedList   | O(min(i, n-i)) | O(min(i, n-i))  | O(min(i, n-i)) | O(1)   | O(min(i, n-i)) |
-//! | BitVec       | O(1)           | O(n-i)*         | O(n-i)         | O(m)*  | O(n-i)         |
 //!
 //! Note that where ties occur, Vec is generally going to be faster than VecDeque, and VecDeque
-//! is generally going to be faster than LinkedList. BitVec is not a general purpose collection, and
-//! therefore cannot reasonably be compared.
+//! is generally going to be faster than LinkedList.
 //!
 //! ## Maps
 //!
-//! For Sets, all operations have the cost of the equivalent Map operation. For
-//! BitSet,
-//! refer to VecMap.
+//! For Sets, all operations have the cost of the equivalent Map operation.
 //!
 //! |          | get       | insert   | remove   | predecessor |
 //! |----------|-----------|----------|----------|-------------|
 //! | HashMap  | O(1)~     | O(1)~*   | O(1)~    | N/A         |
 //! | BTreeMap | O(log n)  | O(log n) | O(log n) | O(log n)    |
-//! | VecMap   | O(1)      | O(1)?    | O(1)     | O(n)        |
-//!
-//! Note that VecMap is *incredibly* inefficient in terms of space. The O(1)
-//! insertion time assumes space for the element is already allocated.
-//! Otherwise, a large key may require a massive reallocation, with no direct
-//! relation to the number of elements in the collection.  VecMap should only be
-//! seriously considered for small keys.
 //!
-//! Note also that BTreeMap's precise performance depends on the value of B.
+//! Note that BTreeMap's precise performance depends on the value of B.
 //!
 //! # Correct and Efficient Usage of Collections
 //!