[all-commits] [llvm/llvm-project] de3b2c: [clang][ScanDeps] Allow PCHs to have different VFS...

[Michael Spencer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: de3b2c293b8bf336f8e1380148cf16b54a794c0c
      https://github.com/llvm/llvm-project/commit/de3b2c293b8bf336f8e1380148cf16b54a794c0c
  Author: Michael Spencer <bigcheesegs at gmail.com>
  Date:   2024-02-23 (Fri, 23 Feb 2024)

  Changed paths:
    M clang/include/clang/Basic/DiagnosticSerializationKinds.td
    M clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
    M clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
    M clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
    M clang/test/ClangScanDeps/optimize-vfs-pch.m
    M llvm/include/llvm/ADT/StringSet.h

  Log Message:
  -----------
  [clang][ScanDeps] Allow PCHs to have different VFS overlays (#82294)

It turns out it's not that uncommon for real code to pass a different
set of VFSs while building a PCH than while using the PCH. This can
cause problems as seen in `test/ClangScanDeps/optimize-vfs-pch.m`. If
you scan `compile-commands-tu-no-vfs-error.json` without -Werror and run
the resulting commands, Clang will emit a fatal error while trying to
emit a note saying that it can't find a remapped header.

This also adds textual tracking of VFSs for prebuilt modules that are
part of an included PCH, as the same issue can occur in a module we are
building if we drop VFSs. This has to be textual because we have no
guarantee the PCH had the same list of VFSs as the current TU.

This uses the `PrebuiltModuleListener` to collect `VFSOverlayFiles`
instead of trying to extract it out of a `serialization::ModuleFile`
each time it's needed. There's not a great way to just store a pointer
to the list of strings in the serialized AST.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications