[Serialization] Ignore the exported module name for XRefs #41984
Conversation
Write the real module name for XRefs in swiftmodule files instead of the exported module name, from `export_as` declarations in module maps. Swiftmodule files are internal details now, they should represent the truth. We keep using the exported module name for the extensions lookup table as clients should still use the exported name. However we may need to write both alternatives in the lookup table in the future if extensions can't be found from clients not importing the exported as module. rdar://90272035
|
@swift-ci Please smoke test |
| @@ -203,7 +203,8 @@ namespace { | |||
| int32_t getNameDataForBase(const NominalTypeDecl *nominal, | |||
| StringRef *dataToWrite = nullptr) { | |||
| if (nominal->getDeclContext()->isModuleScopeContext()) | |||
| return -Serializer.addContainingModuleRef(nominal->getDeclContext()); | |||
| return -Serializer.addContainingModuleRef(nominal->getDeclContext(), | |||
| /*ignoreExport=*/false); | |||
There was a problem hiding this comment.
Why does this one use the exported name still?
There was a problem hiding this comment.
This is used by type-checking to lookup extensions from imported modules. At this point looking them up from what is visible by the client makes sense so I kept that logic as is.
This will likely require more work, it may be both on the lookup side and on what we write to the table. At least with the lookup table in the worst case the compiler won't see some extensions and their members, but it shouldn't crash.
|
|
||
| // Use the overlay with private frameworks. | ||
| // RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk-nosource -I %t) -emit-sil -o /dev/null -F %S/Inputs/privateframeworks/withprivate -swift-version 4 %s -import-objc-header %S/Inputs/privateframeworks/bridging-somekitcore.h -verify | ||
| // RUN: %target-swift-frontend(mock-sdk: %clang-importer-sdk-nosource -I %t) -emit-sil -o /dev/null -F %S/Inputs/privateframeworks/withprivate -swift-version 4 %s -import-objc-header %S/Inputs/privateframeworks/bridging-somekitcore.h |
There was a problem hiding this comment.
The switch from -verify -> not confused me for a little bit there, but IIUC it was superfluous before because no errors were generated. And now there's only one case with -verify, where you do actually check it errors.
So the only actual change here is the addition of that extra test.
There was a problem hiding this comment.
Yeah, the previous presence of -verify only report unexpected warnings I suppose. We're losing this protection by removing -verify from all other RUN lines but it's not a very likely scenario to get warnings here.
The main change is really that using the binary swiftmodules doesn't work anymore, but rebuilding from the swiftinterface still provides the same old behavior.
Write the real module name for XRefs in swiftmodule files instead of the exported module name, which is taken from
export_asdeclarations in module maps. Swiftmodule files are internal details now, they should represent thetruth. Swiftinterface files still display the export as name, so distributed modules will take care of hiding the private module with the
export_asdeclaration.We keep using the exported module name for the extensions lookup table as clients should still expect the exported name. However, we may need to write both alternatives in the lookup table in the future if extensions can't be found from clients not importing the exported as module.
rdar://90272035