The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
`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.
Swift handles Clang submodules as far as controlling visibility, but
pretends that all the declarations live in the top-level module for
the purposes of lookup. This was interacting poorly with another
feature: automatically importing the Swift part of a mixed-source
framework and using that as the "presentation" of a Clang module...
or a submodule in the same framework. Therefore, if you are
- compiling the Swift part of a mixed-source framework, and
- importing one of the framework's (Clang) submodules
name binding would say that the current file imports the Swift module
currently being compiled, in addition to the Clang module we actually
want. Just break the cycle in that case.
This was fixed by Doug's work in e15f67e453. It isn't actually the
underlying problem in rdar://problem/43312726, but it's worth
recording the test case so we don't regress.
...even if the base decl isn't.
This isn't normally possible, but it can come up when an imported type
is import-as-member'd onto an internal Swift declaration. This isn't
even such an unreasonable thing to do, since internal Swift
declarations are exposed in the generated header for an app.
rdar://problem/43312660
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.
For the Optional<Module *> returned by getClangSubmoduleForDecl, the
outside Optional specifies whether there's an answer at all. That
answer can still be null if the declaration comes from a bridging
header. In this particular case, we're guaranteed to get an answer,
but that answer may be null.
rdar://problem/32463543
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
If by chance we haven't imported the members of a particular class,
SIL should not fault them in if at all possible.
The test case was a pain to come up with; it involves a class using
a forward-declared protocol that's actually defined in Swift /in a
non-primary file/, where that protocol is never mentioned in the
primary file and the class's members are never accessed otherwise.
rdar://problem/29535170
So when sorting, don't just jump directly to the Clang decl and get
its name, because there might not be a Clang decl; instead, use the
'objc' attribute if there is one and the protocol's base name if
not. We're not using ProtocolType::compareProtocols because we'd
rather not depend on knowing for sure which Clang module a protocol
lives in.
This wasn't caught until now because it required adopting a protocol
in Objective-C that itself adopted (directly or indirectly) at least
two protocols, at least one of which originally came from Swift.
rdar://problem/26232085
