about summary refs log tree commit diff
diff options
context:
space:
mode:
authorkennytm <kennytm@gmail.com>2018-09-12 12:17:38 +0800
committerGitHub <noreply@github.com>2018-09-12 12:17:38 +0800
commit13ec061df42dfe52d0412297efcb3ce59d540240 (patch)
treec86bc9f3044acb11eda37b1c60ef5b628b0edf26
parent28890152fee5cbf7c6140d56dde837080354bd25 (diff)
parentabe0f027ae23b47dfabeb217aaa56b155d565ae3 (diff)
downloadrust-13ec061df42dfe52d0412297efcb3ce59d540240.tar.gz
rust-13ec061df42dfe52d0412297efcb3ce59d540240.zip
Rollup merge of #54107 - thevaleriemack:master, r=Mark-Simulacrum
Fix typos in libstd hash map

modified growth algo description to read "the first table overflows into the second, and the second into the first." plus smaller typos
-rw-r--r--src/libstd/collections/hash/map.rs8
1 files changed, 4 insertions, 4 deletions
diff --git a/src/libstd/collections/hash/map.rs b/src/libstd/collections/hash/map.rs
index 3e54b502234..804d43f4fc6 100644
--- a/src/libstd/collections/hash/map.rs
+++ b/src/libstd/collections/hash/map.rs
@@ -166,14 +166,14 @@ impl DefaultResizePolicy {
 // Our hash generation scheme consists of generating a 64-bit hash and
 // truncating the most significant bits. When moving to the new table, we
 // simply introduce a new bit to the front of the hash. Therefore, if an
-// elements has ideal index i in the old table, it can have one of two ideal
+// element has ideal index i in the old table, it can have one of two ideal
 // locations in the new table. If the new bit is 0, then the new ideal index
 // is i. If the new bit is 1, then the new ideal index is n + i. Intuitively,
 // we are producing two independent tables of size n, and for each element we
 // independently choose which table to insert it into with equal probability.
-// However the rather than wrapping around themselves on overflowing their
-// indexes, the first table overflows into the first, and the first into the
-// second. Visually, our new table will look something like:
+// However, rather than wrapping around themselves on overflowing their
+// indexes, the first table overflows into the second, and the second into the
+// first. Visually, our new table will look something like:
 //
 // [yy_xxx_xxxx_xxx|xx_yyy_yyyy_yyy]
 //