I should really test before opening PRs

doc/set/BitSet.md

@@ -11,9 +11,9 @@ will be allocated on the stack instead of the heap.
 
 ## Documentation Practices
 
-`BitVec` attempts to replicate the API of the standard-library `BTreeSet` type,
+`BitSet` attempts to replicate the API of the standard-library `BTreeSet` type,
 including inherent methods, trait implementations, and relationships with the
-[`BitVec`] analogue.
+[`BitSet`] analogue.
 
 Items that are either direct ports, or renamed variants, of standard-library
 APIs will have a `## Original` section that links to their standard-library
@@ -33,21 +33,6 @@ that govern the bit-vector’s storage representation in the underlying memory,
 and does *not* take a type parameter to govern what data type it stores (always
 `usize`)
 
-### Macro Construction
-
-Like `Vec`, `BitVec` also has a macro constructor: [`bitvec!`] takes a sequence
-of bit expressions and encodes them at compile-time into a suitable buffer. At
-run-time, this buffer is copied into the heap as a `BitVec` with no extra cost
-beyond the allocation.
-
-```rust
-use bitvec::prelude::*;
-
-let bv = bitvec![0; 10];
-let bv = bitvec![0, 1, 0, 0, 1];
-let bv = bitvec![u16, Msb0; 1; 20];
-```
-
 ### Accessing the internal [`BitVec`]
 
 Since `BitSet` is merely an API over the internal `BitVec`, you can freely
@@ -58,6 +43,7 @@ dedicated methods instead of simple deref:
 
 ```rust
 use bitvec::prelude::*;
+use bitvec::set::BitSet;
 
 fn mutate_bitvec(vec: &mut BitVec) {
   // …
@@ -67,7 +53,10 @@ fn read_bitslice(bits: &BitSlice) {
   // …
 }
 
-let bs = bitset![10, 20, 30];
+let mut bs: BitSet = BitSet::new();
+bs.insert(10);
+bs.insert(20);
+bs.insert(30);
 read_bitslice(bs.as_bitslice());
 mutate_bitvec(bs.as_mut_bitvec());
 ```

doc/set/iter/Range.md

@@ -16,8 +16,9 @@ values instead of references.
 
 ```rust
 use bitvec::prelude::*;
+use bitvec::set::BitSet;
 
-let mut bs = BitSet::new();
+let mut bs: BitSet = BitSet::new();
 bs.insert(1);
 bs.insert(2);
 bs.insert(3);