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>.
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