[all-commits] [llvm/llvm-project] 15c379: [clang][scan-deps] Report a scanned TU's visible m...

[Cyndy Ishida via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 15c3793cdf947be16a4686d26998143fd6487641
      https://github.com/llvm/llvm-project/commit/15c3793cdf947be16a4686d26998143fd6487641
  Author: Cyndy Ishida <cyndy_ishida at apple.com>
  Date:   2025-07-11 (Fri, 11 Jul 2025)

  Changed paths:
    M clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
    M clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
    M clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
    M clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
    M clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
    A clang/test/ClangScanDeps/visible-modules.c
    M clang/tools/clang-scan-deps/ClangScanDeps.cpp
    M clang/tools/clang-scan-deps/Opts.td

  Log Message:
  -----------
  [clang][scan-deps] Report a scanned TU's visible modules (#147969)

Clients of the dependency scanning service may need to add dependencies
based on the visibility of importing modules, for example, when
determining whether a Swift overlay dependency should be brought in
based on whether there's a corresponding **visible** clang module for
it.
This patch introduces a new field `VisibleModules` that contains all the
visible top-level modules in a given TU.
Because visibility is determined by which headers or (sub)modules were
imported, and not top-level module dependencies, the scanner now
performs a separate DFS starting from what was directly imported for
this computation.

In my local performance testing, there was no observable performance
impact.

resolves: rdar://151416358

---------

Co-authored-by: Jan Svoboda <jan at svoboda.ai>



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