rollup merge of #19008: alex/collections-typos
This commit is contained in:
commit
bcd3a4f42b
@ -283,7 +283,7 @@ impl Bitv {
|
||||
x != 0
|
||||
}
|
||||
|
||||
/// Sets the value of a bit at a index `i`.
|
||||
/// Sets the value of a bit at an index `i`.
|
||||
///
|
||||
/// # Panics
|
||||
///
|
||||
@ -582,7 +582,7 @@ impl Bitv {
|
||||
///
|
||||
/// # Panics
|
||||
///
|
||||
/// Panics if the the `Bitv` and slice are of different length.
|
||||
/// Panics if the `Bitv` and slice are of different length.
|
||||
///
|
||||
/// # Example
|
||||
///
|
||||
|
@ -57,7 +57,7 @@ use ring_buf::RingBuf;
|
||||
/// and possibly other factors. Using linear search, searching for a random element is expected
|
||||
/// to take O(B log<sub>B</sub>n) comparisons, which is generally worse than a BST. In practice,
|
||||
/// however, performance is excellent. `BTreeMap` is able to readily outperform `TreeMap` under
|
||||
/// many workloads, and is competetive where it doesn't. BTreeMap also generally *scales* better
|
||||
/// many workloads, and is competitive where it doesn't. BTreeMap also generally *scales* better
|
||||
/// than TreeMap, making it more appropriate for large datasets.
|
||||
///
|
||||
/// However, `TreeMap` may still be more appropriate to use in many contexts. If elements are very
|
||||
|
@ -48,7 +48,7 @@ pub struct Node<K, V> {
|
||||
// theory, if we take full control of allocation like HashMap's RawTable does,
|
||||
// and restrict leaves to max size 256 (not unreasonable for a btree node) we can cut
|
||||
// this down to just (ptr, cap: u8, size: u8, is_leaf: bool). With generic
|
||||
// integer arguments, cap can even move into the the type, reducing this just to
|
||||
// integer arguments, cap can even move into the type, reducing this just to
|
||||
// (ptr, size, is_leaf). This could also have cache benefits for very small nodes, as keys
|
||||
// could bleed into edges and vals.
|
||||
//
|
||||
|
@ -549,7 +549,7 @@ impl String {
|
||||
///
|
||||
/// # Warning
|
||||
///
|
||||
/// This is a O(n) operation as it requires copying every element in the
|
||||
/// This is an O(n) operation as it requires copying every element in the
|
||||
/// buffer.
|
||||
///
|
||||
/// # Panics
|
||||
@ -586,7 +586,7 @@ impl String {
|
||||
///
|
||||
/// # Warning
|
||||
///
|
||||
/// This is a O(n) operation as it requires copying every element in the
|
||||
/// This is an O(n) operation as it requires copying every element in the
|
||||
/// buffer.
|
||||
///
|
||||
/// # Panics
|
||||
|
@ -1057,7 +1057,7 @@ impl<'a, T> VacantEntry<'a, T> {
|
||||
search_stack.map.root.count = temp;
|
||||
value_ref
|
||||
}
|
||||
// Otherwise, find the predeccessor of the last stack node, and insert as normal.
|
||||
// Otherwise, find the predecessor of the last stack node, and insert as normal.
|
||||
else {
|
||||
match *search_stack.get_ref(old_length - 2) {
|
||||
Internal(box ref mut parent) => {
|
||||
@ -1741,7 +1741,7 @@ mod test {
|
||||
// Update it to i^3 using the returned mutable reference.
|
||||
*inserted_val = i * i * i;
|
||||
},
|
||||
_ => panic!("Non-existant key found.")
|
||||
_ => panic!("Non-existent key found.")
|
||||
}
|
||||
assert_eq!(map.get(&i).unwrap(), &(i * i * i));
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user