…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
New code introduced for objcImp class extension support failed to check whether a class extension would be visible to Swift before importing it. This caused Swift to import extensions declared in private headers that ought not to be visible. Add the needed visibility check to the loop.
Fixes rdar://123543707.
Use LLVM apis for understanding TBD files instead of parsing the yaml
directly. This prevents breaking the compiler when TBD-v5 exists which
is in json.
Expands the unofficial “feature” that allows extensions to define @objc methods declared in headers for the same module to also allow this for methods in the private clang module.
Fixes rdar://97810819.
For clang symbols marked with SPI_AVAILABLE, we add SPIAccessControlAttr to them so they will be
considered as SPIs in the AST. To be able to use all these symbols, we also add an implicit SPI import
statement for all clang modules. All clang SPIs belong to the same SPI group named "OBJC_DEFUALT_SPI_GROUP" because clang
currently doesn't support custom SPI group.
rdar://73902734
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.
Add an algorithm to go search the override tables *and* the existing
loaded members of a class for a redeclaration point. The idea is that
both mirrored protocol members and categories offer a way to convince
the Clang Importer to import a property twice. We support a limited form
of this multiple-imports behavior today by allowing the redeclared
property to refine a readonly property into a readwrite property.
To maintain both the refinement behavior and to disambiguate any
remaining cases of ambiguity caused by extensions, attempt to identify
a redeclaration point if we can't identify an override point. Then,
decline to import the redeclared member if we're successful.
Note that the algorithm as presented is subject to import ordering. That
is, if a framework declares both an overlay and a clang module unit, if
the overlay is not loaded or members from the overlay are not installed
in the class by the time we see the declaration we may fail to identify
an redeclaration point.
The regression tests are for rdar://59044692, rdar://59075988, and
rdar://59125907.
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
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
Previously the recommended pattern for having a "private" interface
for a public framework that was easy to strip out was to define an
explicit submodule named 'Private'. However, that makes it all too
easy to have dependencies from the public parts of the module on the
private parts, and other such problems. We're now recommending that
the private module map instead define a parallel module named with
"_Private" as a suffix. Clang already implemented this, but Swift
didn't get the same treatment.
This fix tries to avoid hardcoding too much; it notes that this kind
of remapping is limited to the name 'Private' as the second component
of a module hierarchy, but doesn't actually encode the mapping with the
"_Private" suffix.
rdar://problem/37553763
That is, if a member is redeclarable, use the module of the definition
if possible, and the canonical declaration otherwise. This is
consistent with what we do when we actually import the declaration.
Without this, we can end up dropping declarations.
rdar://problem/32816381
Previously we were checking if a declaration was a redeclaration by
looking at the contextual type, but it should be looking at the
interface type in order to handle categories of classes using
Objective-C lightweight generics.
This also fixes a mistaken reuse of 'containerTy' after I changed its
meaning in the last commit. Doug's review comment was right: it /is/
bad to use an existing name for a new purpose!
More rdar://problem/30785976.
This ensures that any @property redeclarations that appear in class
extensions (a special kind of category in ObjC) do not affect the
primary type of the property as declared in the class itself.
To accomplish this, lookups in importDecl that are checking for
conflicts now no longer pull in new categories/extensions if the
current context is a ClassDecl.
rdar://problem/30785976
