Allows map with std::string keys to be looked up, using a c-string or
stringview without incuring a temporary heap allocation.
Change-Id: Id5b7fd5ac1ab7febf545472f9767273f8637a0de
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/131623
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Allows Hashmaps to be used as keys to other hashmaps.
Change-Id: I557d99515451c55e599dda847e15ce8e2b4500c5
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/112282
Kokoro: Ben Clayton <bclayton@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Don't return a raw pointer to the map entry's value, instead return a new Reference which re-looks up the entry if the map is mutated.
Change-Id: I031749785faeac98e2a129a776493cb0371a5cb9
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/110540
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Previously Hashmap used to internally use a Hashset which held entries
of key-value pairs. This was cute, but meant that a Hashset held mutable
entries, which was a bag-of-bugs waiting to happen (change the entry to
hash as something different and you're now in an entirely broken state).
Pull the complex bits of Hashset out to HashmapBase, and have both
derive from that. I've opted for inheritance over composition here to
reduce the amount of structure chasing you'd have to do without
debugger pretty-printers.
Change-Id: I99e72244b69206a994edabfefd0e28d5d74d08d9
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/108240
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Its not unreasonable for the create callback to mutate the map. If this
happened, the map would be corrupted.
This change fixes this.
Change-Id: I2bb3820061c741c6da36ebe3667cb6b878515a27
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/100903
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Useful for knowing if you have to look up an entry again since the last
lookup.
Change-Id: Ib0374627ef5cd7fcff7fa2d9e72b4214260b2df3
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/100901
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
STL std::hash<T*> implementations have a tendency of just reinterpreting the
pointer as a size_t. This is fast, but produces a bad hash, as most pointers
tend to be 4 or 16 byte aligned. The lack of entropy in the LSBs causes
clustering of hashmap slots. Use tint::utils::Hasher to get better hashes.
Change-Id: Ife768d573cd1875e746ca9d77a4ac19e43b06aca
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/99281
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Algorithmically faster than `std::unordered_[map|set]`, and use a small vector internally reducing heap allocations.
Change-Id: I9c0b00468272d9d7c72ab077d832d66d1368500c
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/98123
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Dan Sinclair <dsinclair@chromium.org>
