-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SymbolGraphGen] consider modules not equal if they're not from the same compiler #58421
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@@ -0,0 +1,19 @@ | |||
// RUN: %empty-directory(%t) | |||
// RUN: cp -r %S/Inputs/EmitWhileBuilding/EmitWhileBuilding.framework %t | |||
// RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk) -enable-objc-interop -emit-module-path %t/EmitWhileBuilding.framework/Modules/EmitWhileBuilding.swiftmodule/%target-swiftmodule-name -import-underlying-module -F %t -module-name EmitWhileBuilding -disable-objc-attr-requires-foundation-module %s %S/Inputs/EmitWhileBuilding/Extra.swift -emit-symbol-graph -emit-symbol-graph-dir %t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also have a test that checks the behavior when using swift-symbolgraph-extract
, since the behaviors regarding @_export import
are different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense! I'll write up a test and push it today.
@swift-ci Please smoke test |
@swift-ci Please smoke test and merge |
@swift-ci Please smoke test Linux |
rdar://98808363 functionally reverts #58421
Resolves rdar://92263972
In #41577, symbols were lifted into the main module's symbol graph if they originated from an
@_exported import
module. However, the comparison was based on the modules' names, which caused the comparison to spuriously consider symbols to be "re-exported" if an underlying Clang module was present.1 This PR tightens that check to also consider whether the modules being compared for re-exporting are both Swift or non-Swift modules.Footnotes
When
-import-underlying-module
is given to the frontend, any headers considered to be part of the same module are aggregated into a separate module with the same name as the Swift module, which is then implicitly@_exported import
ed into the Swift module. As the comparison added in [SymbolGraphGen] Emit symbols from exported modules #41577 was based on the name of the module, this means that everything that was declared in the Swift module was considered to be re-exported, even if it is technically an extension on a foreign type! Check the test that was added in this PR for an example. ↩