[5.7-04182022][SymbolGraphGen] consider modules not equal if they're not from the same compiler #58492
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 #58421
Explanation: #41577 made it so that symbols were lifted into a module's symbol graph when their source module was re-exported via an
@_exported import
declaration. However, the comparison that checked this was based purely on the module's name, creating some false positives. This PR tightens that comparison to treat symbols in a foreign-type extension from being treated as part of the underlying Clang module (which is implicitly re-exported) and erroneously placed in the main module's symbol graph.Scope: The change is isolated to SymbolGraphGen, and should only move symbols from the main symbol graph to module-extension symbol graphs.
Radar: rdar://92263972
Risk: Low. This won't affect normal compilation. There is no impact to the symbol graph data, only where it gets saved.
Testing: A new lit test,
SymbolGraph/ClangImporter/ForeignExtensions.swift
, has been added to verify that extensions on foreign types don't get added to the main module's symbol graph.