We keep a map from function name to source location so we don't have to
do it via looking up a source location from the AST. However, since
function names can be long, we actually use a hash of the function name
as the key.
Additionally, we can't rely on Clang's printing of function names via
the AST, so we just demangle the name instead.
This is necessary to implement
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.
As David says, this could be a plain hash map, maybe hash_code isn't hashable, but it must have some way to convert to a plain integer.
This also deserves a comment about why the key here is a hash code and not the full string. The purpose of this is to avoid storing another copy of all the mangled names, which are large. In the case of a hash collision, it is possible that the wrong location will be returned. The probability is roughly #functions / size_t_max, so pretty negligible, especially for a 64-bit platform. In any case, the consequences of a collision are that we use the wrong source location, which is a diagnostic quality issue, which isn't severe.
This would be a good use case for a fast content hash, such as blake3. I believe it would be really useful for LLD to have such a fast content hash for parellelizing symbol resolution and other deduplication actions, so I think it is worth a FIXME or TODO to use a fast content hash when one is available.