...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
This reverts part of r14563, which swapped out the mirroring of
Objective-C initializers into subclasses. We still need to do this
when a subclass does not declare it's designated initializers. At
least the mirroring code is more robust, and marks declarations as
implicit so they won't show up when printed.
Swift SVN r14633
Right now we have a hack to mirror ObjC protocol methods into an imported
ObjC class, because Swift's lookup only looks into superclasses, not into
protocols (by default, anyway). This already isn't great because it's wrong
for @optional, but it was particularly bad if /two/ superclasses conformed
to the same protocol (directly or indirectly). Because the mirrored methods
weren't marked as overrides, the type checker would consider them both as
possibilities, leading to strange errors like this:
<REPL Input>:1:1: error: ambiguous use of 'description'
w.description()
^
AppKit.NSWindow:268:8: note: found this candidate
func description() -> String
^
ObjectiveC.NSObject:72:8: note: found this candidate
func description() -> String
^
Now, we check to see if a superclass conforms to a protocol already before
mirroring its methods into the current class or category.
<rdar://problem/16102321> and possibly also <rdar://problem/16038085>
Swift SVN r14189
More precisely, import anonymous enums with no fixed underlying type as Int
if they would have fit in a 32-bit signed integer. If not, we can't be sure
"Int" is a valid type for code that compiles for multiple architectures.
(Currently that means we'll fall back to the C type, which is probably /also/
wrong for multiple architectures. We could try to be smarter here, since we
have the number of required bits, but let's start with just this.)
Also, remove existing code that assumed that any 64-bit underlying type was
compatible with Int, which it definitely isn't any more on 32-bit platforms.
Part of <rdar://problem/15368372>
Swift SVN r14089
It isn't great to get this by accident, but the importer SDK contains
more minimal overlay modules than the ones actually used for real SDKs.
Fix up some tests that weren't consistent about whether or not the
minimal overlays were being used.
<rdar://problem/16048012>
Swift SVN r13835
This eliminates a pile of extra casting when interacting with
Objective-C APIs. Addresses the majority of <rdar://problem/14044307>,
but there is still cleanup to do.
Swift SVN r13780
Retrieve the getter/setter selector from the underlying Clang node,
when there is one. This allows using and overriding Objective-C
properties that have custom getters and setters (i.e., for Boolean
properties where the getter is named isPropName), which narrowly
addresses <rdar://problem/15877160>.
One cannot declare a property in Swift and give it a different
selector. That would require a more general attribute such as
<rdar://problem/16019773>.
Swift SVN r13680
Instead, just import them as a pair of methods. This is obviously suboptimal,
but better than the alternative in which you can see the property, but
attempting to use the accessor with the customized name results in a crash
at runtime.
Swift SVN r12755
Direct access to ivars is very rare in our frameworks, and they can conflict
with property names (which we should prefer). On top of that, we weren't
even emitting the right code to access them correctly.
<rdar://problem/15818047>
Swift SVN r12604
We can look through typealiases that come from Swift, but once we get one
from Clang we should be able to just use it.
This was already working in the last commit, but had no tests.
Swift SVN r12086
Rather than append the "Proto" suffix to all imported Objective-C
protocols, which can be confusing, whitelist those protocols that we
do have to rename. Only NSObject falls into this category so far.
Fixes <rdar://problem/15741699>.
Swift SVN r11856
More specifically, instance methods on root objects are also class methods,
because the metatype for that class will inherit from the root class.
(That is, NSObject's metatype extends NSObject.)
This is necessary to allow calling, say, -respondsToSelector: on a class.
Unfortunately, it also brings in every other method on NSObject, including
"informal protocol" category methods like -awakeFromNib. We should probably
disprefer these in code completion, especially if they're declared in another
module, but it is perfectly legal to call these methods on Class objects in
Objective-C.
<rdar://problem/13371711>
Swift SVN r11614
and check for CF_ENUM/CF_OPTIONS, which NS_ENUM/NS_OPTIONS expand to.
This:
- Simplifies code
- Handles CF_ENUM/CF_OPTIONS enums
- Handles correctly an NS_ENUM/NS_OPTIONS enum that was itself expanded from another macro.
Swift SVN r11542
It does not matter what we actually do, just make sure we don't crash -- we did
not have tests for bitfields previously. Related: rdar://15671755
Swift SVN r11363
This change moves the swift overlay modules from Clang importer mock sdk to a
central location. (Otherwise we try to deserialize the Foundation overlay for
the system framework, and crash because we don't find all declarations in
our mock sdk.)
Swift SVN r11297
