[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