Skip to content

GitLab

Switch branch/tag
  1. 13 Jan, 2021 2 commits
  3. 05 Dec, 2020 1 commit
  5. 04 Dec, 2020 1 commit
  7. 11 Apr, 2020 2 commits
  9. 20 Jan, 2020 2 commits
  11. 22 Oct, 2019 1 commit
    • Alex Hornby's avatar
      Fix for case where calling shrink_to_fit could make the map larger · df565f17
      Alex Hornby authored 
      Reproduced issue by adding new test shrink_to_fit_after_insert.  Checked it was failing before doing any changes

With the test in place fixes were:

1. Make CHashMap::reserve be the place the amortizing growth factor LENGTH_MULTIPLIER is applied, rather than Table::with_capacity ( non-CHashMap::reserve users of Table::with_capacity are requesting a specific capacity and just need load factor applied, not amortizing growth multiplier )

2. Apply load factor consistently in Table::with_capacity() vs CHashMap::capacity()

3. Apply MINIMUM_CAPACITY in CHashMap::capacity to stop reported capacity being below requested.

4. Add test known_size_with_capacity_matches_shrink to test the initial capacity+shrink case

Tested via cargo test
      df565f17
  13. 09 Oct, 2019 1 commit
  15. 28 Feb, 2019 1 commit
  17. 27 Feb, 2019 1 commit
  19. 26 Feb, 2019 1 commit
  21. 25 Feb, 2019 3 commits