[SymbolGraphGen] distinguish between headers of the same name in different modules #82112
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
rdar://152676102
|
@swift-ci Please smoke test |
franklinsch
approved these changes
Jun 9, 2025
QuietMisdreavus
added a commit
that referenced
this pull request
Jun 9, 2025
…erent modules (#82112) Resolves rdar://152676102 In Objective-C, it's reasonable to sort extensions of your dependency's types into headers that match the name of that type. However, this runs into a bug in SymbolGraphGen when it comes time to generate Swift symbol graphs for that Objective-C code: At the moment, it only differentiates between modules based on their base name, regardless of their parent modules (if any). This causes these extensions to be incorrectly sorted into the _extending module's_ symbol graph, rather than in an extension symbol graph where it can be displayed with the _extended module_. When processed with Swift-DocC, it would cause these symbols to disappear. This PR updates the `areModulesEqual` function used by the `SymbolGraphASTWalker` to consider the fully-qualified module name for comparisons, rather than just the module's base name, causing situations like the test's `Dependency.DependencyClass` and `HeaderCollision.DependencyClass` to be properly distinguished from each other.
QuietMisdreavus
added a commit
that referenced
this pull request
Jun 10, 2025
…n different modules (#82120) - **Explanation**: Makes SymbolGraphGen use fully-qualified module names when comparing modules for determining symbol sources. - **Scope**: Fixes an uncommon bug when extending an Objective-C type using a header with the same name as the source module's header. - **Issues**: rdar://152676102 - **Original PRs**: #82112 - **Risk**: Low. The change does not affect normal compilation, and the change will only affect which symbol graph a symbol is sorted into, and shouldn't introduce any crashes. - **Testing**: Automated tests verify the change. - **Reviewers**: @franklinsch
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.
Resolves rdar://152676102
In Objective-C, it's reasonable to sort extensions of your dependency's types into headers that match the name of that type. However, this runs into a bug in SymbolGraphGen when it comes time to generate Swift symbol graphs for that Objective-C code: At the moment, it only differentiates between modules based on their base name, regardless of their parent modules (if any). This causes these extensions to be incorrectly sorted into the extending module's symbol graph, rather than in an extension symbol graph where it can be displayed with the extended module. When processed with Swift-DocC, it would cause these symbols to disappear.
This PR updates the
areModulesEqualfunction used by theSymbolGraphASTWalkerto consider the fully-qualified module name for comparisons, rather than just the module's base name, causing situations like the test'sDependency.DependencyClassandHeaderCollision.DependencyClassto be properly distinguished from each other.