[all-commits] [llvm/llvm-project] 6bbccc: [clang][modules] Adopt `FileEntryRef` in the `Head...
Jan Svoboda via All-commits
all-commits at lists.llvm.org
Thu Sep 28 09:28:17 PDT 2023
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 6bbccc0bcb36689507ba98ef338527d43334c7e7
https://github.com/llvm/llvm-project/commit/6bbccc0bcb36689507ba98ef338527d43334c7e7
Author: Jan Svoboda <jan_svoboda at apple.com>
Date: 2023-09-28 (Thu, 28 Sep 2023)
Changed paths:
M clang/include/clang/Basic/FileManager.h
M clang/lib/Basic/FileManager.cpp
M clang/lib/Serialization/ASTWriter.cpp
Log Message:
-----------
[clang][modules] Adopt `FileEntryRef` in the `HeaderFileInfo` block in PCM files (#67383)
This patch adopts `FileEntryRef` in the `HeaderFileInfo`-writing part of
`ASTWriter`.
First, this patch removes the loop over
`FileManager::VirtualFileEntries`. It's redundant, since all virtual
file entries are also present in `SeenFileEntries` and thus already in
`UIDToFiles`.
Second, since we now no longer rely on
`FileEntry::getLastRef()`/`FileEntry::getName()`, this patch takes care
to establish which path gets used for each UID by picking the
`FileEntryRef` with the most "`<`" name (instead of just relying on the
`StringMap` iteration order).
Note that which `FileEntry`/`FileEntryRef` objects we pick for each UID
for serialization into the `llvm::OnDiskChainedHashTable` doesn't really
matter. The hash function only includes the file size and modification
time. The file name only plays role during resolution of hash
collisions, in which case it goes through `FileManager` and resolves to
a `FileEntry` that gets pointer-compared with the queried `FileEntry`.
(Reincarnation of [D143414](https://reviews.llvm.org/D143414) and
[D142780](https://reviews.llvm.org/D142780).)
More information about the All-commits
mailing list