There are a few cases where the same class occurs in AppKit and UIKit,
with different designated initializers in each. Comment these out
because we can't handle this now.
Swift SVN r16363
methods with conflicting selectors.
We were doing this in a very ad hoc manner before; centralizing the
lookup table should make this significantly more robust. There's also
some scaffolding here to handle initializers better.
Fixes <rdar://problem/16516638>.
Swift SVN r16349
Previously, we would import the init method as a FuncDecl, which
wasn't actually supposed to be used by anything, and then created a
separate ConstructorDecl via importSpecialMember(). That's insane:
just have VisitObjCMethodDecl() produce a ConstructorDecl directly
when given an init method. Should be NFC.
Swift SVN r16313
This makes a number of changes to the selector-splitting
heuristics. Specifically:
- Eliminate last-word splitting, and with it the notion of
multi-words. We only split at prepositions now.
- Introduce the notion of "linking verbs" such as "will" or
"should"; when these show up, we refuse to split a selector, which
helps with delegates.
- Eliminate the special case for "get" and "set". It wasn't
helping.
Swift SVN r16265
If it already has a node it should be the node we want the swift decl to point to,
e.g. the @interface definition. Otherwise we may replace it with a @class forward declaration.
rdar://16560290
Swift SVN r16254
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
clang::ObjCMethodDecl::findPropertyDecl does a very general lookup to see if
a particular method /could/ be interpreted as a property accessor, but in
other places we were just using isPropertyAccessor() to decide whether a
method was /actually/ a property accessor. We should use the more conservative
of the two; I'm not sure if the former can /change/ if new protocols are
added (via categories).
This does cause one problem: the setter is now not available in any way on
the adopting class. We should still be exposing it as a method, even though
it's not available as a property.
Swift SVN r16035
In Objective-C, any method with no arguments can be used with dot syntax, as
can any method that takes one argument whose name starts with "set". This
commit adds a frontend-only flag -enable-objc-implicit-properties to look for
"setter-like" methods that match up with "getter-like" methods to import them
as Swift properties. By default, such methods are just considered unrelated
methods.
Part of <rdar://problem/16215476>
Swift SVN r16025
Seed the whitelist with the designated initializers for NSObject,
NSDocument, and UIDocument. We'll grow this list over time.
Fixes <rdar://problem/16521299>.
Swift SVN r16013
Regardless of the heuristic we choose when importing Objective-C
selectors into Swift method names, there will be poor cases. Allow us
to bake specific mappings into the compiler so we can address those
cases without having to modify the Objective-C headers.
Part of <rdar://problem/16341485>.
Swift SVN r15984
This makes sure that Clang uses the mangled class names for
Swift-defined classes. Should be last compiler-side piece of
<rdar://problem/15506580>.
Swift SVN r15977
...and teach the type-checker to prefer variables to functions.
This matters in Objective-C, where you may have these two members:
@property NSURL *URL;
- (void)URL:(NSURL *)url resourceDidFailLoadingWithReason:(NSString *)reason;
This doesn't happen often, but we should do the right thing when it does.
We still won't import a property named 'foo' if there is already a method
'-foo' that takes no arguments.
<rdar://problem/16383845>
Swift SVN r15963
Also class versions of instance methods on root classes.
No tests because nothing is actually using the implicit flag besides
SIL printing.
Swift SVN r15953
This backs off trying to bridge CF*Ref forward declarations to C*VoidPointer, which throws away all the typedef sugar. Continue importing these as COpaquePointer for now. This should fix the complete_from_cocoa tests.
Swift SVN r15890
