about summary refs log tree commit diff
path: root/src/rustllvm/RustWrapper.cpp
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2016-10-03 04:25:58 -0700
committerGitHub <noreply@github.com>2016-10-03 04:25:58 -0700
commit75df685d28947ea7d2422a24f14aa1254da1aeb4 (patch)
treeb407534e3141ef6818cbcc2709bec0118d5ffb45 /src/rustllvm/RustWrapper.cpp
parentf3745653e10e366e7e119a12c178a59ab6394007 (diff)
parent607d2973da7bd5895a5e84a65ba5174527bee904 (diff)
downloadrust-75df685d28947ea7d2422a24f14aa1254da1aeb4.tar.gz
rust-75df685d28947ea7d2422a24f14aa1254da1aeb4.zip
Auto merge of #36766 - nnethercote:hash-span-capacity, r=bluss
Clarify HashMap's capacity handling.

HashMap has two notions of "capacity":

- "Usable capacity": the number of elements a hash map can hold without
  resizing. This is the meaning of "capacity" used in HashMap's API,
  e.g. the `with_capacity()` function.

- "Internal capacity": the number of allocated slots. Except for the
  zero case, it is always larger than the usable capacity (because some
  slots must be left empty) and is always a power of two.

HashMap's code is confusing because it does a poor job of
distinguishing these two meanings. I propose using two different terms
for these two concepts. Because "capacity" is already used in HashMap's
API to mean "usable capacity", I will use a different word for "internal
capacity". I propose "span", though I'm happy to consider other names.
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions