rust-lang / rust-lang/hashbrown

HashTable grows even though capacity is not exceeded

Open
#602 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
3k
Forks
358
Avg merge
11h 57m
Merged PRs (30d)
2

Description

HashTable::with_capacity docs say:

The hash table will be able to hold at least capacity elements without reallocating.

The following test shows that this statement is incorrect:

#[test]
fn foo() {
    let capacity = 100;
    let mut hash_table = HashTable::with_capacity(capacity);
    for i in 0u64..1_000 {
        dbg!(i);
        assert!(hash_table.len() < capacity);
        let hasher =
            |_: &_| unreachable!("hasher won't be called because there is capacity left");
        let eq = |j: &u64| *j == i;
        let Entry::Vacant(entry) = hash_table.entry(i, eq, hasher) else {
            unreachable!("actually unreachable");
        };
        entry.insert(i);
        if hash_table.len() == capacity {
            hash_table.find_entry(i, eq).unwrap().remove();
        }
    }
}

Expectation:
As the assert shows, every time the loop begins there is at least one capacity left. The HashTable does not need to grow and it will not call our hasher in HashTable::entry.

Reality:
The HashTable attempts to grow and calls the hasher, triggering the unreachable. The debug prints tell us that this happens at i=112.

This is a problem because it prevents you from writing code that relies on HashTable not growing when enough capacity has been allocated. You should be able to write such code.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating HashTable::with_capacity, HashTable::entry, and find_entry, then reproduce the issue with the test shown in the report. Trace the capacity check around i=112 and add a regression test showing that insertion does not grow or call the hasher while the table remains below its requested capacity.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
data
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.