[6.0🍒][Dependency Scanning] Use a standalone DependencyScanningFilesystem
on the scanner, sharing a common status
cache from Clang's dependency service cache
#72933
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #72932
Explanation: Built-in Clang dependency scanner uses a
DependencyScanningFilesystem
which relies on thestat
cache owned by its parentDependencyScanningService
. This way repeated attempts to query a filesystem entry hit the cache during scanning. Until now, the Swift scanner did not share thisstat
cache so filesystem entry lookups by the Swift scanner went directly to the "real" underlying filesystem, resulting in often duplicated calls tostat
. This change makes the Swift scanner use/share Clang Scanner'sstat
cache, unifying the filesystem abstraction for the two.Risk: Low. This change affects a code-path that is currently disabled in the compiler by-default (Explicit Modules). The addition for Explicit Module Builds is to now rely on existing caching technology already in-use and well-validated by the built-in Clang dependency scanner.
Testing: Existing test suite coverage exercises the relevant code-paths affected by this functional change.
Reviewed By: @cachemeifyoucan