Temporarily disabling the ClangImporter/private_frameworks.swift test to
continue making progress on the rebranch.
Test error message (truncated file-paths):
```
swift/test/Inputs/clang-importer-sdk/swift-modules/CoreGraphics.swift:38:20: warning: function call causes an infinite recursion
return lhs.value == rhs.value
^
swift/test/Inputs/clang-importer-sdk/swift-modules/Foundation.swift:224:28: warning: 'UnsafeSendable' is deprecated: Use @unchecked Sendable instead
extension NSError : Error, UnsafeSendable { // expected-warning{{'UnsafeSendable' is deprecated: Use @unchecked Sendable instead}}
^
swift/test/Inputs/clang-importer-sdk/swift-modules/Foundation.swift:241:10: warning: function call causes an infinite recursion
return x as NSError
^
swift/test/ClangImporter/Inputs/privateframeworks/overlay/SomeKit.swift:2:8: warning: module 'Foundation' was not compiled with library evolution support; using it means binary compatibility for 'SomeKit' can't be guaranteed
import Foundation
^
<unknown>:0: warning: module interfaces are only supported with Swift language version 5 or later (currently using -swift-version 4)
swift/test/ClangImporter/Inputs/privateframeworks/bridging-somekitcore.h:1:2: note: in module 'SomeKitCore' imported from swift/test/ClangImporter/Inputs/privateframeworks/bridging-somekitcore.h:1:
^
swift/test/ClangImporter/Inputs/privateframeworks/withprivate/SomeKitCore.framework/Headers/SKWidget.h:4:12: error: 'SKWidget' has different definitions in different modules; definition in module 'SomeKitCore.SKWidget' is here
@interface SKWidget : NSObject
^
swift/test/ClangImporter/Inputs/privateframeworks/withoutprivate/SomeKit.framework/Headers/SKWidget.h:3:12: note: definition in module 'SomeKit.SKWidget' is here
@interface SKWidget : NSObject
^
```
The radar to fix the test failure on macOS and re-enable the test is:
rdar://113413583
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
A refinement of Doug's e3207f753c from a year ago to account for
trying to reference an import-as-member error enum /through/ an
overlay when it's in a Clang module using 'export_as'. The problem is
that importing error enums synthesizes a corresponding struct, and
that struct doesn't have a Clang node and so when it isn't found in
the right module the compiler didn't know to allow it anyway.
I know, right?
(Looking at the source change might be simpler than trying to read
the above paragraph.)
I'm still not 100% sure on how this occurred in the original
(Apple-internal) projects hitting this, but I think it's just that we
handle all import-as-member types at once, and the clients were using
something else from a type that contained the error enum, and then
that resulted in the error struct's conformances getting written into
a serialized swiftmodule.
rdar://problem/47152185
If a declaration provided in a Swift overlay has the same signature as
a declaration imported from the Clang module it overlays, or some
private framework that re-exports its interface through that Clang
module, the declaration provided in the Swift overlay shadows the one
imported from Clang.
To make this work for unqualified lookup, allow the shadowing rules to
kick in there as well. Make this a very narrow fix, because the
underlying problems that prevented us from doing this shadowing still
persist.
Fixes rdar://problem/35691030 and its several dupes.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Test more kinds of entities, including through serialized SIL, and
verify that other combinations work (e.g., building the overlay
against the public module but using it with the private version).
When serializing cross-references to a (private) module that is
re-exported through another (public) module, record the
cross-reference as if the entity were found in named public module.
Finishes rdar://problem/34438586.
A public C module can be expressed as the combination of several
private modules at build time, where that structure is "collapsed"
into a single public module for client use. In such cases, the symbols
associated with the public module can actually be seen as coming from
the private module (e.g. at the time the Swift overlay is built),
which fools our overlay-specific hacks. When a module states that it
is re-exported via another, public module, teach semantic analysis to
treat the entity "as if" it came from the re-exporting public module.
Part of rdar://problem/34438586.
