[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