Use the HBuilder interface to provide default implementations of llvm::hash_value.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/Support/HashBuilder.h | ||
---|---|---|
410 | This was suggested as part of https://reviews.llvm.org/D102943. A couple things to consider: The default implementation of hash_value would always go through ArrayRef<uint8_t>: Using hash_value with that mechanism requires calling llvm::hash_value or (using llvm::hash_value) explicitly. I need to brush up on ADL and template functions (I think that's what involved here). Again, that looks acceptable to me. What do you think ? |
llvm/include/llvm/Support/HashBuilder.h | ||
---|---|---|
101–106 | Noticing now that this trait is independent of HashBuilder's template parameters. I suggest moving it outside HashBuilder in a prep commit (probably doesn't need a review), maybe into a detail namespace like llvm::hashbuilder_detail. | |
410 | One option would be to throw HashCodeHasher and HashCodeHashBuilder into a detail namespace to discourage anyone trying to use HashCodeHashBuilder directly. There's an asymmetric relationship:
|
llvm/include/llvm/Support/HashBuilder.h | ||
---|---|---|
30–37 | This change should be a separate NFC commit, since it touches a lot of lines (and isn't directly related) | |
91 | Diff would be reduced if teh public: didn't move before teh static_assert | |
410 | Probably cleaner to use the same name for the detail namespace as above. |
llvm/include/llvm/Support/HashBuilder.h | ||
---|---|---|
30–37 |
LGTM, with one more inline comment.
llvm/include/llvm/Support/HashBuilder.h | ||
---|---|---|
424–425 | Please move this typedef into the detail namespace as well, since it's not intended to be used directly. Could even be inside HashCodeHasher: class HashCodeHasher { public: //... using Builder = HashBuilder<...>; }; but up to you. |
This change should be a separate NFC commit, since it touches a lot of lines (and isn't directly related)