[SERVER-43041] DefaultHash: avoid using Abseil internals Created: 26/Aug/19  Updated: 06/Dec/22  Resolved: 13/Aug/20

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Billy Donahue Assignee: Backlog - Service Architecture
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Participants:

 Comments   
Comment by Billy Donahue [ 26/Aug/19 ]

Difficult.

I thought we'd just make an absl::node_hash_set<K> and extract its hasher, relying on substitution failure to catch K for which there is no default hasher.

https://mongodbcr.appspot.com/510430012/

But no, that doesn't work because of some unusual absl internals.

https://github.com/mongodb/mongo/blob/def30acb316289d5cb95ecdf2654c3ca919c6a46/src/third_party/abseil-cpp-master/abseil-cpp/absl/container/internal/raw_hash_set.h#L677

This appears inside the raw_hash_set class template:

// Give an early error when key_type is not hashable/eq. 
auto KeyTypeCanBeHashed(const Hash& h, const key_type& k) -> decltype(h(k)); 

The particular ->decltype(h(k)) syntax makes it impossible to make the container for a key that doesn't have a default hasher and rely on sfinae to catch the cases where a default hasher can't be determined.  Small repro: https://godbolt.org/z/-XCK-O

 

We might be able to convince them to make the containers more sfinae friendly, or to make the default_hasher metafunction public.

 

We can also just make our OWN metafunction that determines default hasher and use that for our stdx::unordered_{map,set} containers.

In the case that our metafunction can't find a hasher, we fall back to absl's hasher choices, and if that fails, well, we tried.

 

 

Generated at Thu Feb 08 05:02:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.