This is what we use to drop the variadic parameter on UIActionSheet and
UIAlertView's initializers, along with secretly adding a category to each
to provide the one-fewer-parameter init method implementation. However,
we haven't been using the Swift name for the method to generate Objective-C
calls for a while now--we use the @objc attribute. And that was still using
the original selector, and so we crashed.
Fixed by passing the new selector to the @objc attribute.
<rdar://problem/17012323>
Swift SVN r18582
Thankfully, Doug already put in infrastructure for this, so it just required
adding one more entry to the table.
<rdar://problem/16995980>
Swift SVN r18537
These types come from <sys/types.h> indirectly and show up in a few
interesting functions like arc4random_uniform.
This commit also introduces a new test file for mapping fixed-sized integers,
to eliminate boilerplate as we continue to rack up aliases for UInt*.
<rdar://problem/16978349>
Swift SVN r18505
BOOL should also be _Bool on x86-64 simulator, but the clang importer preprocessor doesn't appear to have the necessary #defines to distinguish that currently.
Swift SVN r18159
Introduce the UIApplicationMain attribute, and check that it's only applied to nongeneric classes that conform to UIApplicationDelegate.
Swift SVN r18048
Previously, we were using the context where the initializer was declared in Objective-C, rather than where it was being imported. This meant that we wouldn't treat an inherited designated initializer as a designated initializer if (for example) the designated-initializer marking came from our internal table of DIs. Fixes <rdar://problem/16838515>.
Swift SVN r17968
We now allow bridging so long as both K and V can be bridged to
Objective-C, as determined by _BridgedToObjectiveC conformance. Note
that Dictionary's implementation still needs to handle this, which is
tracked separately.
Swift SVN r17859
Note that this is still under -objc-bridge-dictionary, but otherwise
this should be all of the functionality needed for
<rdar://problem/16870626>.
Swift SVN r17848
...which, like NSObject, is a protocol that has the same name as a class.
Doing this more generally is tracked in <rdar://problem/16206627>.
Swift SVN r17583
Also, look through one layer of parentheses in general for macros, rather
than special-casing it for each token count.
<rdar://problem/16198517>
Swift SVN r17460
We'd rather show dispatch_async as
// new
func dispatch_async(queue: dispatch_queue_t!, block: dispatch_block_t!)
than
// old
func dispatch_async(queue: dispatch_queue_t!, block: (() -> Void)!)
which was only happening because we were trying to hide the @objc_block
annotation when possible. That's not necessary when we have a typealias.
<rdar://problem/16679280>
Swift SVN r17273
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
Previously, this declaration:
typedef NS_OPTIONS(NSUInteger, NSABitmapFormat5) {
NSAA16d,
NSAB32d,
};
...would import with members .A16d and .B32d, which is not necessarily
correct. (Is it "NS_AA_16d", or "NSA_A_16d"?) Be more conservative here.
Swift SVN r17125
Swift sometimes has a different notion of visibility, even for Clang modules.
In particular, this was causing the C version of NSUTF8StringEncoding
(from Foundation) to show up in AppKit, bypassing the Swift version in the
overlay.
We still want to search for redeclarations of functions, typedefs, and globals,
since these are often repeated in multiple modules without harm. The decl will
still have a "home" module, but this should allow them to be found by lookup.
<rdar://problem/16396994> and possibly <rdar://problem/14665250>
Swift SVN r16762
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
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
We started tracking statistics for these in r16529, but because we've
"always" done this for initializers, it's trivial to just implement
the splitting. As with initializers, we synthesize a named argument of
type '()' to capture the part of the first selector piece that follows
the class name.
Swift SVN r16530
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
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
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
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
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
