[Fast Dependency Scanner] Ensure Swift modules don't depend on self. #32083
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
|
@swift-ci test |
|
Build failed |
|
Build failed |
|
@swift-ci test |
nkcsgexi
approved these changes
May 29, 2020
| @@ -125,12 +125,15 @@ static std::vector<ModuleDependencyID> resolveDirectDependencies( | |||
| knownModules); | |||
| } | |||
|
|
|||
| // Look for overlays for each of the Clang modules. The Swift module | |||
| // Look for overlays for each of the Clang modules. The Swift module | |||
There was a problem hiding this comment.
Suggested change
| // Look for overlays for each of the Clang modules. The Swift m�odule | |
| // Look for overlays for each of the Clang modules. The Swift module |
There was a problem hiding this comment.
Thanks for the catch. I need to figure out why my Xcode keeps inserting these in strange places.
When resolving direct dependencies for a given Swift module, we go over all Clang module dependencies and add, as additional dependencies, their Swift overlays. We find overlays by querying `ASTContext::getModuleDependencies` with the Clang module's name. If the Clang module in question is a dependency of a Swift module with the same name, we will end up adding the Swift module as its own dependence. e.g. - Swift A depends on Clang A - Add Clang A to dependencies of Swift A - We look for overlays of Clang A, by name, and find Swift A - Add Swift A to dependencies of Swift A From what I can tell, the logic upstream is sound, and `getModuleDependencies` is doing the right thing, so this change is simply restricting what gets added when we are looking for overlays. Resolves rdar://problem/63731428
artemcm
force-pushed
the
RecycleYourSwiftModules
branch
from
14051e0 to
99a0919
Compare
|
@swift-ci test |
|
Build failed |
|
Build failed |
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.
When resolving direct dependencies for a given Swift module, we go over all Clang module dependencies and add, as additional dependencies, their Swift overlays. We find overlays by querying
ASTContext::getModuleDependencieswith the Clang module's name. If the Clang module in question is a dependency of a Swift module with the same name, we will end up adding the Swift module as its own dependence.e.g.
From what I can tell, the logic upstream is sound, and
getModuleDependenciesis doing the right thing, so this change is simply restricting what gets added when we are resolving direct dependencies and looking for overlays.Resolves rdar://problem/63731428