Skip to content

[🍒][clang][scan-deps] Report a scanned TU's visible modules (#147969) #10987

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: stable/20240723
Choose a base branch
from

Conversation

cyndyishida
Copy link

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


(cherry picked from commit 15c3793)

@cyndyishida cyndyishida requested a review from a team as a code owner July 11, 2025 18:54
@cyndyishida cyndyishida changed the title [clang][scan-deps] Report a scanned TU's visible modules (#147969) [🍒][clang][scan-deps] Report a scanned TU's visible modules (#147969) Jul 11, 2025
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 <[email protected]>
(cherry picked from commit 15c3793)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant