The code completion change is a (fairly minor) regression, because we
are now printing parameter names when we don't want to. I'll come back
to that.
Swift SVN r16438
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
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
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
...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
Import a selector into a Swift method name, performing splitting at
that point. Use the resulting method name to determine the argument
names of the parameters, rather than trying to chop up the selector
again. There's more refactoring to do here.
This fixes a longstanding bug where the first argument of an
Objective-C method got the internal parameter name when it should
have gotten no name at all.
Swift SVN r15850
...so that the enumerators of this declaration:
typedef NS_OPTIONS(NSUInteger, NSKeyValueObservingOptions) {
NSKeyValueObservingOptionNew = 0x01,
NSKeyValueObservingOptionOld = 0x02,
NSKeyValueObservingOptionInitial NS_ENUM_AVAILABLE(10_5, 2_0) = 0x04,
NSKeyValueObservingOptionPrior NS_ENUM_AVAILABLE(10_5, 2_0) = 0x08
};
...come in as .New, .Old, .Initial, and .Prior. The code checks for plurals
of the form -s, -es, and -ies, which covers all of the NS_OPTIONS in our SDK.
<rdar://problem/16448966>
Swift SVN r15712
Otherwise we'd import NSNumberFormatterBehavior10_0 of
NSNumberFormatterBehavior as '10_0'. (Yes, you could escape it, but...)
<rdar://problem/16452174>
Swift SVN r15710
For example:
func foo(a: id)
now gets a fixit to turn 'id' into 'AnyObject'.
This relies on the ClangImporter recording the translation as it
processes declarations whose types are remapped.
Swift SVN r15668
With this in place, remove the hacks that peeked at the imported Clang
node to determine the selector for a method. We're all
attribute-driven now. Part of <rdar://problem/16019773>.
Swift SVN r15663
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
Now that we represent the Objective-C runtime names of classes and
protocols in a uniform way, stop peeking into the Clang AST nodes to
get this information for imported classes and protocols. This is
better layering and helps test that new code path.
Swift SVN r15632
We can just get it from the instance type, if the instance type has been fully initialized, which is the case except during parsing of type decls when the decls' own types are being formed.
Swift SVN r15598
@partial_interface is like @class, but it allows the user to write categories
or (eventually) subclasses in their Objective-C headers even though the
class will be implemented in Swift. The resolution rules are thus exactly the
same as for class.
I've included a template hack to allow you to keep building without switching
to the new internal Clang repo; in this case you will see one test failure.
<rdar://problem/16426884>
Swift SVN r15523
You can't actually call these initializers with an existential yet, but nor could you safely call the init methods anyway. At least you'll be able to conform to NSCoding with an initializer rather than an "init method". Fixes <rdar://problem/15595471>.
Swift SVN r15521
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
When we see an unresolved @protocol in a Clang module, we now check the name
against the protocols in the Swift module with the same name like we do for
classes.
More <rdar://problem/16295994>
Swift SVN r15472
This keeps us from accidentally stripping off something semantically
meaningful, like in Foundation's NSDirectoryEnumerationOptions:
NSDirectoryEnumerationSkipsSubdirectoryDescendants
NSDirectoryEnumerationSkipsPackageDescendants
NSDirectoryEnumerationSkipsHiddenFiles
<rdar://problem/15496513>
Swift SVN r15436
