[PATCH] D137304: [clang] Store filename per include instead of mutating filename

Ben Langmuir via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 2 17:04:45 PDT 2022


benlangmuir created this revision.
Herald added a project: All.
benlangmuir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137304

Files:
  clang/include/clang/Basic/FileEntry.h
  clang/include/clang/Basic/SourceManager.h
  clang/lib/Basic/SourceManager.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/Frontend/show-includes-symlink.c
  clang/test/Preprocessor/header-symlink.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D137304.472809.patch
Type: text/x-patch
Size: 20701 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20221103/7f98d445/attachment-0001.bin>


More information about the cfe-commits mailing list