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
