Hack the clang importer to drop the 'otherButtonTitles:' argument when we see the UIActionSheet or UIAlertView init methods, so we'll end up importing them as the non-variadic initializers added by the overlay.
Swift SVN r16717
Previously, we didn't correctly handle acronyms as single words, leading to
importing the NS16BitLittleEndianBitmapFormat enumerator of NSBitmapFormat as
"S16BitLittleEndianBitmapFormat". Now we get "NS16BitLittleEndianBitmapFormat",
which is a little better. See the examples for a few more ways this shakes out.
<rdar://problem/16683848>
Swift SVN r16682
them with uses of TypeExpr instead. The remaining uses of
MetaTypeExpr (which will be renamed soon) are places where we
are applying the ".dynamicType" virtual property to an expression.
Unadorned uses of types in code, e.g. the Int in "Int.self" are
now represented with TypeExpr.
One unfortunate travesty that doing this work revealed is that we
are extremely sloppy and terrible about maintaining location information
in implicitly generated decls, and our invariants vary quite a bit. This
is really horrible, but I'm not sure whether I'll go fix the hacks or not.
This patch perpetuates the existing crimes, but makes them more visible.
NFC!
Swift SVN r16646
Before we create a new initializer, check whether it would collide
with existing initializers. If it's better than the existing
initializer, mark the existing one as unavailable; if it's not better,
don't build it.
In support of this, we tweak a few things w.r.t. unavailble
declarations:
- An unavailable declaration is shadowed by an available one,
- Don't emit SIL unavailable, imported initializers
This fixes the last problem with <rdar://problem/16509024>.
Swift SVN r16611
The use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
Basically, if an imported enumeration case is referenced without qualification as an argument to a '==' application (E.g., "foo.bar == .Baz"), and the enumeration type had not previously been resolved, overloads to '==' will be added to the global scope while performing overload resolution. This means the overloads will be ignored while solving for that application, but will be available for subsequent applications. (So you'll get an "expression does not type check" error the first time around, but not for subsequent applications of '==' to that enumeration type.)
The Equatable protocol is rather lightweight, however, and adding it to imported types directly results in no meaningful overhead to type check performance; we should just add it outright. As things evolve, though, it'll be worth considering how to make the type checker more amenable to lazy declarations.
Swift SVN r16557
As noted in the FIXME, this is a hack. We need to do a bit of
infrastructure work before we can detect and suppress duplicates like
this in a meaningful way. Name lookup already does a similar thing for
ambiguity-resolution purposes. However, doing this here makes the
printed modules much cleaner.
look significantly more reasonable.
Swift SVN r16531
Factory initializers express an initializer that produces an object of
the given type, but is not inherited and not designated. Although they
have a syntactic form for presentation purposes (-> ClassName), there
is no way to specify or implement them within Swift. Rather, factory
initializers are created when importing an Objective-C factory method
that returns the class type rather than instancetype.
Swift SVN r16528
Convenience factory initializers are convenience initializers produced
by importing an Objective-C factory method as a convenience
initializer. The distinction is currently only used to eliminate the
awful layering violation I recently introduced in name lookup, which
was consulting Clang AST nodes directly. It will also be useful in
SILGen.
Swift SVN r16527
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
Help guide users over to the initializers with the 'unavailable' message, e.g.,
objc_factory_method.swift:24:18: error: 'hiveWithQueen' is unavailable: use
initializer 'Hive(withQueen:)'
Swift SVN r16498
When an Objective-C class method follows the naming convention of a
factory method, i.e., its starting words match the ending words of the
class name, import it as a convenience initializer when it also:
- Returns instancetype (i.e., dynamic Self in Swift parlance)
- Has no NSError** parameters, which indicate the potential for failures
This is under a new flag (-enable-objc-factory-method-constructors)
because it is not generally functional. However, this is a step toward
<rdar://problem/16509024>.
Swift SVN r16479
Switch the "does this imported declaration override a declaration in
the superclass?" check to perform lookups based on what actually gets
into Swift, rather than looking into the Objective-C class, because
the Objective-C class isn't representative.
Additionally, explicitly avoid adding implicit initializers to an
Objective-C-imported class.
Problems fixed here are tested by an upcoming commit.
Swift SVN r16464
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
