The following commit contains a failing test demonstrating the problem:
It generates a .swiftinterface for module MainModule, but this .swiftinterface then fails to compile with the error message:
To summarize the situation:
- The Swift module SubModule imports Clang modules ForeignA and ForeignB. Both ForeignA and ForeignB include a textual header containing the struct ForeignStruct.
- SubModule re-exports ForeignB but not ForeignA. ForeignStruct is therefore available to clients of SubModule; those clients can use it either using the unqualified name ForeignStruct or the qualified name ForeignB.ForeignStruct, but not ForeignA.ForeignStruct (because SubModule doesn't re-export ForeignA).
- The Swift module MainModule imports SubModule and uses ForeignStruct in the signature of funcTakingForeignStruct. When MainModule is compiled to a .swiftinterface file, that signature erroneously refers to ForeignStruct as ForeignA.ForeignStruct instead of ForeignB.ForeignStruct. Because of this, the resulting .swiftinterface file does not compile.
I discovered this issue in the course of investigating a CI failure on https://github.com/apple/swift/pull/32404. The repro above corresponds to the situation in the failing test as follows:
- SubModule is Glibc
- ForeignA is SwiftOverlayShims
- ForeignB is SwiftGlibc
- The textual header is sys/time.h, and ForeignStruct is struct timeval
I believe this needs to be fixed in TypePrinter::printModuleContext(), but I'm not sure exactly how.