Depends on https://reviews.llvm.org/D137303
This change is not ready to land, but I wanted to put it up for early review in case the approach looks wrong to anyone. I'm also curious if there are any related cases this does not handle. I verified it fixes the /showIncludes and preprocessor examples mentioned in the comments on https://reviews.llvm.org/D135220 and https://github.com/llvm/llvm-project/issues/58726.
When including a header, store the filename per include (per FileInfo)
rather than storing it once in the ContentCache and mutating it. This
fixes the spelling of includes for -E and --show-includes when working
with symlinks/hardlinks for headers included multiple times.
Logically, the filename and FileEntryRef belong to the FileInfo, but to
avoid increasing the size of SLocEntry we indirect them in a new struct
NamedContentCache.
TODO
- Evaluate the performance cost of indirecting ContentCache an extra level.
- Audit uses of FileInfos to see if we need to do extra for for NamedFileInfos.
- Consider making the FileEntryRef changes here the default -- it doesn't make sense to me that FileEntryRef == or DenseMap would match FileEntry pointer semantics instead of filename semantics.
It's possible this could be factored out as a follow-up, and/or moved up to the Named ContentCache level. (Not sure... asking a question really...)