This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Teach the driver to pass the SDK version it computes (from the SDK
settings JSON in a Darwin-based platform's SDK) down into the frontend.
The frontend then sets that SDK version in the LLVM module, which
eventually makes its way into the Mach-O file.
Last part of rdar://problem/60332732.
An upstream clang changed ASTSourceDescriptor to not have a const
Module pointer. const_cast here to make this agree.
(cherry picked from commit a49bceeedf)
When we found Objective-C methods via selector lookup, we would skip the
“should we even try to import this?” check. If the Swift-name-as-derived-
from-Objective-C is different from the actual Swift name, we might try to
(redundantly) import something from the generated Objective-C header,
which can lead to crashes. The specific method causing problems was defined
like this in Swift:
@objc public class func using(index: AnyObject) -> AnyObject? { return nil }
which produced an Objective-C method like this:
+ (id _Nullable)usingIndex:(id _Nonnull)index;
The Swift name derived from the Objective-C method is `usingIndex(_:)`, which
of course does not match `using(index:)`, meaning that we think these two
methods are different (they aren’t).
The safe fix is to check whether we should import a given Objective-C method
declaration along the found-via-Objective-C-selector path, like we do with
normal name lookup. A longer term fix is to emit swift_name attributes for
such methods.
Fixes the fiendish Clang importer crash in rdar://problem/60046206.
Recent clang side change merges ObjCCategoryDecl with the same name. All re-declarations
of a category points to the first category as the canonical one. This patch keeps these
non-canonical redeclarations as separate extensions in Swift.
rdar://problem/59744309
Because all metaclasses ultimately inherit from NSObject, instance
members of NSObject are also visible as static members of NSObject.
If the instance member is a property, we import the getter as an
ordinary static method, and not a static property.
The lazy loading path normally checks for the presence of alternate
decls with the same name, but it was failing to do this check if the
imported decl was a property and the alternate decl was attached to
the accessor and not the property itself.
This wasn't a problem until recently, because we weren't lazy loading
members of NSObject itself, since it had protocol conformances; now
that we are, this problem was exposed.
Fixes <rdar://problem/59170514>.
Let's try calling ObjCInterface::lookupMethod() instead. This also
eliminates an order dependency between selector conflict checking
and protocol member mirroring, which fixes a diagnostics regression
once lazy loading is enabled for mirrored protocol members.
Lazy loading checked if the ClangDecl was hidden, but loading all
members did not. Let's make loadAllMembers() behave like the lazy
path, and fix some of the mock SDKs in the test suite.
Add a platform kind and availability attributes for macCatalyst. macCatalyst
uses iOS version numbers and inherits availability from iOS attributes unless
a macCatalyst attribute is explicitly provided.
The Clang Importer allows for the creation of otherwise illegal Swift
ASTs because it does not run redeclaration checking or override
checking. These behaviors are also not a part of our test suite.
Correct the first issue by re-instating the old emergent behavior of
member loading occurring at all points in the class hierarchy before
a (lazy) lookup.
Correct the second issue by adding a regression test for a common
failure mode in the post-re-entrant-lookup Clang Importer.
We cannot stop accepting these cases, but a future compiler will warn
about them.
Attacks rdar://58493370
Delayed categories only existed to keep
ClangImporter/objc_redeclared_properties passing. But this test
appears to exhibit incorrect behavior as written.
The clang importer implements limited behavior for overwriting
variable declarations. If that overwrite occurs somewhere else in the
class hierarchy, the declaration is rewritten as a Swift override. The
remaining case is categories, which enable all sorts of awful
redeclaration behaviors. When a bridging header declares a category
that tries to stomp the API surface of another category, we need to
import that category first, and we would import that category first - by
accident. Re-entrancy does have its upsides.
In order to keep the tests passing post re-entrant lookup, we stubbed in a hack that delayed
categories in the bridging header so they were installed last, which
meant the variable merging logic would mostly decline to import those
properties. But the rest of the world expects the opposite: Bridging
header contents are more sacred than the rest of the SDK and must be
installed *first* in order for a number of nightmarish header hacks to
go through.
Unwind the old, incorrect emergent behavior and re-establish the
correct behavior as the way the world ought to work.
Resolves rdar://58493356, rdar://58493357, rdar://58493362, rdar://58493370
