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>.
The framework versions already superseded the files here, so let's not
even bother building and packaging them. There /are/ still a few
frameworks that aren't shipping their own API notes at the moment,
however, though some of them are deprecated in their entirety.
rdar://problem/32908357
If NSInteger and NSUInteger typedefs are available in the current Clang context, use them when mapping Swift's Int and UInt to Clang types. This gives us consistent method and property type encodings for @objc methods with Clang, fixing rdar://problem/17506068.
For the most part this was just "check isInstanceProperty"; the one feature not yet implemented
is the emission of ObjC metadata for class properties.
rdar://problem/16830785
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
Also, remove calls to isSwiftReservedName in
ClangImporter::Implementation::importName(), since 'true' and 'false'
are now keywords and rdar://problem/13187570 is no longer a problem.
rdar://problem/18797808
Swift SVN r23244
Also, use "#include <objc/NSObject.h>" instead of "@import ObjectiveC;"
to get access to BOOL, SEL, NSObject, and NSString.
This allows generated headers to be used in Objective-C++ contexts, where
modules don't yet work. The dependencies will unfortunately need to be
imported separately (because there's not a direct mapping from module name
back to header file), but that's still better than just being incompatible.
<rdar://problem/16796627>
Swift SVN r17272
That is, NSObject.isEqual(someObj) should call +isEqual:, not be equivalent
to someObj.isEqual, unless there's a type context that says otherwise.
<rdar://problem/16527717>
Swift SVN r15955
Protocols can declare methods as being unavailable, as they do
in NSObjectProtocol (e.g., 'retain'). We both need to flag these
uses, but understand this for protocol conformance. For protocol
conformance, treat unavailable methods as if they were marked
optional. The compiler will not allow you to use these methods
anyway.
This finishes up support for:
<rdar://problem/16331335> Ban ObjC ARC entry points
Swift SVN r15644
This is a direct translation which happens when a Clang declaration
gets translated to a Swift declaration. This changed, coupled
with the current @availability checking (which is still limited)
now prohibits cases such as using 'NSDeallocateObject()' or
'- (BOOL) allowsWeakReference' from Swift.
Interestingly, it doesn't catch uses of -retain/-release yet, because
those methods are marked unavailable in the NSObject *protocol*.
While the attributes are being mapped over, the @availability
checking needs to be enhanced to replicate more of what Clang does
for this case.
Swift SVN r15643
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
Right now we have a hack to mirror ObjC protocol methods into an imported
ObjC class, because Swift's lookup only looks into superclasses, not into
protocols (by default, anyway). This already isn't great because it's wrong
for @optional, but it was particularly bad if /two/ superclasses conformed
to the same protocol (directly or indirectly). Because the mirrored methods
weren't marked as overrides, the type checker would consider them both as
possibilities, leading to strange errors like this:
<REPL Input>:1:1: error: ambiguous use of 'description'
w.description()
^
AppKit.NSWindow:268:8: note: found this candidate
func description() -> String
^
ObjectiveC.NSObject:72:8: note: found this candidate
func description() -> String
^
Now, we check to see if a superclass conforms to a protocol already before
mirroring its methods into the current class or category.
<rdar://problem/16102321> and possibly also <rdar://problem/16038085>
Swift SVN r14189
It isn't great to get this by accident, but the importer SDK contains
more minimal overlay modules than the ones actually used for real SDKs.
Fix up some tests that weren't consistent about whether or not the
minimal overlays were being used.
<rdar://problem/16048012>
Swift SVN r13835
Rather than append the "Proto" suffix to all imported Objective-C
protocols, which can be confusing, whitelist those protocols that we
do have to rename. Only NSObject falls into this category so far.
Fixes <rdar://problem/15741699>.
Swift SVN r11856
More specifically, instance methods on root objects are also class methods,
because the metatype for that class will inherit from the root class.
(That is, NSObject's metatype extends NSObject.)
This is necessary to allow calling, say, -respondsToSelector: on a class.
Unfortunately, it also brings in every other method on NSObject, including
"informal protocol" category methods like -awakeFromNib. We should probably
disprefer these in code completion, especially if they're declared in another
module, but it is perfectly legal to call these methods on Class objects in
Objective-C.
<rdar://problem/13371711>
Swift SVN r11614
