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
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
Allows AnyObject[] to occur in @objc methods/properties/etc., then
bridges between the two in SILGen based on the new array
implementation. <rdar://problem/16535097>.
Note that this commit does not change the Clang module importer to
import NSArray* as AnyObject[] (yet).
Swift SVN r16004
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
That is, NSObject.isEqual(someObj) should call +isEqual:, not be equivalent
to someObj.isEqual, unless there's a type context that says otherwise.
<rdar://problem/16527717>
Swift SVN r15955
The parameter names in C functions are not API in C and can easily be
inconsistent from one redeclaration to another. Therefore, those
parameter names are not considered API.
Swift SVN r15853
...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
When we see pointer types in function or method parameters, import them as the bridged CMutablePointer/CConstPointer types instead of UnsafePointer, enabling the array and inout conversions with imported APIs.
Swift SVN r15705
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
This keeps us from accidentally stripping off something semantically
meaningful, like in Foundation's NSDirectoryEnumerationOptions:
NSDirectoryEnumerationSkipsSubdirectoryDescendants
NSDirectoryEnumerationSkipsPackageDescendants
NSDirectoryEnumerationSkipsHiddenFiles
<rdar://problem/15496513>
Swift SVN r15436
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
When importing an Objective-C class, import all of the initializers in
all of its superclasses. When we have no information about designated
initializers for a class, the initializers come in as subobject
initializers. When we do have information about designated
initializers, we (1) use it to sort out subobject from complete object
initializers in that class, and (2) assume that all initializers from
superclasses are complete object initializers. Overall, this better
matches Objective-C's semantics.
Swift SVN r14841
