diff options
author | JF Bastien <jfb@google.com> | 2016-04-09 20:04:34 +0000 |
---|---|---|
committer | JF Bastien <jfb@google.com> | 2016-04-09 20:04:34 +0000 |
commit | 6e94b16739fac1a7ed5bb27cb56c643cb7ab01e9 (patch) | |
tree | 1c2836b631aa2fb68bfab80ed6bbac635b04ae73 /llvm/lib/CodeGen/MachineFunction.cpp | |
parent | e86dd022c6084e3a12616fc594fb2d6584fcc9c2 (diff) | |
download | llvm-6e94b16739fac1a7ed5bb27cb56c643cb7ab01e9.zip llvm-6e94b16739fac1a7ed5bb27cb56c643cb7ab01e9.tar.gz llvm-6e94b16739fac1a7ed5bb27cb56c643cb7ab01e9.tar.bz2 |
is_integral_or_enum ❥ enum class ⇒ hashable enum class
Summary:
As discussed in D18775 making AtomicOrdering an enum class makes it non-hashable, which shouldn't be the case. Hashing.h defines hash_value for all is_integral_or_enum, but type_traits.h's definition of is_integral_or_enum only checks for *inplicit* conversion to integral types which leaves enum classes out and is very confusing because is_enum is true for enum classes.
This patch:
- Adds a check for is_enum when determining is_integral_or_enum.
- Explicitly converts the value parameter in hash_value to handle enum class hashing.
Note that the warning at the top of Hashing.h still applies: each execution of the program has a high probability of producing a different hash_code for a given input. Thus their values are not stable to save or persist, and should only be used during the execution for the construction of hashing datastructures.
Reviewers: dberlin, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18938
llvm-svn: 265879
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunction.cpp')
0 files changed, 0 insertions, 0 deletions