`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
The code does naive lookup of Swift types using the type name, but sometimes the Swift type we're looking for only has that name in its @objc attribute. This change makes the compiler exclude certain Swift declarations from matching even if the Swift name is the same (namely, not being available in Obj-C or having a mismatched `@objc` name) and continue to find the correct declaration without using lookup by name.
Fixes SR-4827
...rather than replacing particular macros with an 'annotate'
attribute and then looking for that. This isn't /really/ any
particular win except maybe ever-so-slightly faster module imports
(with one fewer attribute being added to each declaration in a
mixed-source header).
This doesn't remove the SWIFT_CLASS_EXTRA, SWIFT_PROTOCOL_EXTRA, or
SWIFT_ENUM_EXTRA macros from PrintAsObjC (note that
SWIFT_EXTENSION_EXTRA was never used). They're not exactly needed
anymore, but they're not doing any harm if someone else is using them.
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
This allows a previously-working case of Objective-C forward-declaring
a type in a /different/ Swift module to continue working, as long as
the Swift context being compiled manages to import the other module
properly (including its generated header). This isn't really our
recommended pattern---that would be to @import the module in the
bridging header and forego the forward declaration---but it doesn't
cost much to keep it working. It's also a place where textual and
precompiled bridging headers behaved differently, because precompiled
ones are processed much earlier.
https://bugs.swift.org/browse/SR-3798
