This moves the DenseMapInfo implementation for hash_code into Hashing.h, removing the need to include Hashing.h (and thus <string>) in DenseMapInfo.h. This follows the general convention of declaring DenseMapInfo for types that we own in the respective header. The remaining implementations in DenseMapInfo.h are all for types we do not own.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
nice, makes sense. I'm surprised more #include <string> instances weren't needed in other downstream headers and .cpp files.
Comment Actions
I landed the necessary (at least for my build) include fixups ahead of time in https://github.com/llvm/llvm-project/commit/cfb53d8e6d6383c9622331224acf0abb03cb1713. Interestingly no <string> includes in particular were needed.
Comment Actions
Thanks for looking at this @nikic - are you using https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html to identify candidate includes or have you been able to get another tool like iwyu to help?