Skip to content

Releases: oxidecomputer/iddqd

iddqd 0.4.1

16 May 01:22

Choose a tag to compare

Fixed

  • Fixed a logic bug in TriHashMap::remove_unique, when key1 matches, and one of key2 and key3 matches, but not the other.

iddqd 0.4.0

04 May 21:44

Choose a tag to compare

Changed

  • The internal implementation for item storage has been changed to use a linear slot-based buffer, resulting in 2-3x performance improvements for most workloads.
  • The maps now have a limit of u32::MAX (4 294 967 295) elements at any given time. This limit is very unlikely to be reached in practice.

Fixed

  • All mutation methods for IdHashMap and IdOrdMap are now panic-safe, in the sense that a panic in user code will not corrupt the map. This does not currently extend to BiHashMap and TriHashMap

Added

  • Many more unit and property-based tests covering various kinds of pathological user implementations. We now have high confidence that arbitraily buggy user implementations (as long as they're in safe Rust) will not result in undefined behavior.

iddqd 0.3.18

23 Apr 01:10

Choose a tag to compare

Fixed

  • Fixed a rehashing bug in hash map reserve and shrink-to-fit methods. (Due to an oversight, these methods were previously not part of our property-based tests. Now they are. Sorry about that!)

iddqd 0.3.17

22 Nov 18:28

Choose a tag to compare

Added

  • Capacity management methods for all map types:
    • reserve(&mut self, additional: usize) reserves capacity for at least additional more elements.
    • shrink_to_fit(&mut self) shrinks capacity to fit the current length.
    • shrink_to(&mut self, min_capacity: usize) shrinks capacity to at least min_capacity.
    • try_reserve(&mut self, additional: usize) -> Result<(), TryReserveError>: fallible capacity reservation for hash maps (IdHashMap, BiHashMap, TriHashMap).
  • New TryReserveError type in the errors module for reporting allocation failures.

Notes

  • For IdOrdMap, the reserve and shrink methods only affect item storage. The internal BTreeSet used for item ordering does not support capacity control.
  • IdOrdMap does not provide try_reserve, since the underlying BTreeSet does not expose fallible reservation operations.

Fixed

  • Fixed an instance of potential unsoundness in retain.

Changed

The Extend implementations now pre-reserve capacity based on the iterator's size_hint.

iddqd 0.3.16

09 Nov 19:44

Choose a tag to compare

Added

  • clear methods for all map types to remove all items from the map.
  • Optionally, serialize ID maps as maps (JSON objects) rather than sequences (JSON arrays):
    • New IdHashMapAsMap, BiHashMapAsMap, TriHashMapAsMap, and IdOrdMapAsMap marker types to use with #[serde(with = ...)].
    • The default deserializer for each map now accepts both maps and sequences.

Changed

  • Documentation improvements for serde implementations.

iddqd 0.3.15

09 Nov 01:03

Choose a tag to compare

Added

  • retain methods that allow filtering items in place based on a predicate.
  • IdOrdMap::first, first_entry, last, last_entry, pop_first, and pop_last methods for accessing entries at the beginning and end of the map.
  • BiHashMap::with_hasher and TriHashMap::with_hasher are now const fn.

Changed

  • Reduced memory footprint for BiHashMap and TriHashMap.

iddqd 0.3.14

29 Sep 18:22

Choose a tag to compare

Fixed

Replaced obsolete doc_auto_cfg with doc_cfg, to fix Rust nightly builds with the doc_cfg flag enabled.

iddqd 0.3.13

15 Sep 00:24

Choose a tag to compare

Changed

  • iddqd now depends on serde_core rather than serde. This allows iddqd's compilation to be parallelized with serde_derive.
  • Internal dependency updates: foldhash updated to 0.2, and hashbrown updated to 0.16.

iddqd 0.3.12

12 Sep 19:40

Choose a tag to compare

Added

The following methods are now const fn:

  • IdOrdMap::new
  • IdHashMap::with_hasher

iddqd 0.3.11

14 Aug 18:33

Choose a tag to compare

Fixed

The type definitions for IdHashMap, BiHashMap, TriHashMap, and IdOrdMap no longer require IdHashItem, BiHashItem, TriHashItem, and IdOrdItem, respectively. This matches the standard library's HashMap and BTreeMap type definitions which don't require Hash + Eq or Ord bounds.

Thanks to aatifsyed for your first contribution!