[Dependency Scanning] Make dependency scanner cache specific to a given target triple. #39326
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…`SwiftSource` These kinds of modules differ from `SwiftTextual` modules in that they do not have an interface and have source-files. It is cleaner to enforce this distinction with types, instead of checking for interface optionality everywhere.
artemcm
commented
Sep 15, 2021
| @@ -49,6 +49,8 @@ typedef struct { | |||
| } swiftscan_string_set_t; | |||
|
|
|||
| typedef enum { | |||
| // This dependency info encodes two ModuleDependencyKind types: | |||
There was a problem hiding this comment.
For now, preserve the format used by libSwiftScan. Once we teach the clients about the new dependency kind, we can then add it here.
|
Existing scanner tests ensure we do not regress on current functionality. |
|
@swift-ci please test |
|
Build failed |
artemcm
force-pushed
the
MultiTargetScan
branch
from
36cfa49 to
0dadf60
Compare
|
@swift-ci please test |
nkcsgexi
approved these changes
Sep 20, 2021
…he current scanning action's target triple And only resolve cached dependencies that came from scanning actions with the same target triple. This change means that the `GlobalModuleDependenciesCache` must be configured with a specific target triple for every scannig action, and it will only resolve previously-found dependencies from previous scannig actions using the exact same triple. Furthermore, the `GlobalModuleDependenciesCache` separately tracks source-file-based module dependencies as those represent main Swift modules of previous scanning actions, and we must be able to resolve those regardless of the target triple. Resolves rdar://83105455
artemcm
force-pushed
the
MultiTargetScan
branch
from
0dadf60 to
709676c
Compare
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In order to do so, first refactor the dependency kinds to model the main modules of individual scanning actions as separate dependency kind:
SwiftSource. These kinds of modules differ fromSwiftTextualmodules in that they do not have an interface and have source-files. It is cleaner to enforce this distinction with types, instead of checking for interface optionality everywhere, as we did prior to this change.Then, make
GlobalModuleDependenciesCacheaware of the current scanning action's target triple and only resolve cached dependencies that came from scanning actions with the same target triple.This change means that the
GlobalModuleDependenciesCachemust be configured with a specific target triple for every scanning action, and it will only resolve previously-found dependencies from previous scannig actions using the exact same triple only.Furthermore, the
GlobalModuleDependenciesCachenow separately tracks source-file-based module dependencies as those represent main Swift modules of previous scanning actions, and we must be able to resolve those regardless of the target triple.This change is largely required due to the introduction of the
-clang-targetoptimization which means that the driver is no longer re-scanning Clang modules against different target sets in a given module's build graph.Resolves rdar://83105455