Per the comments, hash_code values "are not stable to save or
persist", so are unsuitable for the module hash, which must persist
across compilations for the implicit module hashes to match. Note that
in practice, today, hash_code are stable. But this is an
implementation detail, with a clear FIXME indicating we should switch
to a per-execution seed.
The stability of MD5 also allows modules cross-compilation use-cases.
The size_t underlying storage for hash_code varying across platforms
could cause mismatching hashes when cross-compiling from a 64bit
target to a 32bit target.
Note that native endianness is still used for the hash computation. So hashes
will differ between platforms of different endianness.
I have added these in the same line as existing hash_value functions. The idea being others may also need to hash those objects.
Let me know if you would rather move some/all of these locally in CompilerInvocation.cpp.