Defer to DenseMapInfo<T>::isEqual instead of operator==(T,T).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/unittests/ADT/DenseMapTest.cpp | ||
---|---|---|
755–756 | It is worth testing a type were isEqual and operator== disagree? The tombstone and empty keys in StringRef would be an example where they don't work with operator== https://github.com/llvm/llvm-project/blob/a68bbf42fa680c7159165be8915d73e012c50f96/llvm/include/llvm/ADT/StringRef.h#L911-L931 |
llvm/unittests/ADT/DenseMapTest.cpp | ||
---|---|---|
755–756 | i'd rather not depend on the implementation details for DenseMapInfo<StringRef>, added a custom type into the test instead. |
llvm/include/llvm/ADT/DenseMapInfo.h | ||
---|---|---|
326–329 | As this will be instantiated for each combination of types in our variant, I think the approach taken in https://reviews.llvm.org/D151079 is slightly better for compilation speed, although it is not as simple as this. I would love to suggest C-style variadic functions to avoid any template instantiation, i.e. bool operator()(...) const { return false; } but I don't think the behavior is guaranteed for non-POD user-defined types and some compilers will create a copy. |
llvm/include/llvm/ADT/DenseMapInfo.h | ||
---|---|---|
326–329 | yes that was my concern as well, hence we had an offline discussion with @sammccall and he was kind enough to come up with go/phab/D151557. so i'll abandon this patch in favor of it. |
As this will be instantiated for each combination of types in our variant, I think the approach taken in https://reviews.llvm.org/D151079 is slightly better for compilation speed, although it is not as simple as this.
I would love to suggest C-style variadic functions to avoid any template instantiation, i.e.
but I don't think the behavior is guaranteed for non-POD user-defined types and some compilers will create a copy.