Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
Non-null attributes can indicate non-optionality of pointers. While
these non-null attributes are generally less useful than the
nullability type specifiers, they are occasionally used in the
wild. Addresses rdar://problem/18428099.
Swift SVN r23733
If an imported C struct has no __nonnull pointer fields, then we can give a default initializer that zeroes all of its fields. This becomes a requirement when working with partially-imported types like NSDecimal. NSDecimal has bitfields Swift can't see yet, so it's impossible to DI, but the Foundation functions that work with NSDecimal all emit their result by out parameter, and without access to its fields it is impossible to initialize an NSDecimal for use with one of these functions. Implement the initializer using a builtin that gets lowered by IRGen; this is also made necessary by the fact that Swift has only a partial view of the struct, so we can't form a complete zero initializer until we have the definitive type layout from Clang.
Swift SVN r23727
We have a module map referring to it as dispatch.h, and
this capitalization matches the system, so let's go with it.
Fixes running test/ClangModules/blocks_parse.swift on
case-sensitive file systems. Apparently I'm the only
person building on a case-sensitive file system.
Swift SVN r23380
Also, remove calls to isSwiftReservedName in
ClangImporter::Implementation::importName(), since 'true' and 'false'
are now keywords and rdar://problem/13187570 is no longer a problem.
rdar://problem/18797808
Swift SVN r23244
- Make NSZone functions unavailable radar://16688847
- Distributed Objects subsystem should not be imported into Swift radar://16689104
- NSCalendarDate is available in Swift, but deprecated radar://16689207
- Do not import NSMethodSignature class and related methods radar://16689329
- NSInvocationOperation should be unavailble in Swift radar://17921785
Swift SVN r22090
This is a hack that allows us to support accessibility APIs in Swift.
It addresses radar://17509751.
A class might conform to both NSAccessibility (containing accessibility
properties) and individual accessibility protocols (containing
accessibility methods with the same names as the properties). This should
not compile (but currently happens to compile). To avoid the problem down
the road, we import setters and getters instead of the accessibility
properties from NSAccessibility.
Swift SVN r21757
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
Without this, we try to bring these in as CF types, and then ARC tries to
manage them, and the program crashes.
<rdar://problem/17211521>
Swift SVN r21081
This is a step towards making the framework easier to use in Swift; in the
actual headers, these are typed as "CFTypeRef" or "const CFTypeRef", which
is not considered Hashable (and thus cannot be put in a dictionary).
Unfortunately, CFStringRef is also not hashable, so we're not there yet,
but at least this allows a freer conversion to NSString.
Part of <rdar://problem/17162475>
Swift SVN r20931
Background: if a Clang module /only/ imports submodules from another module,
we would lose all re-exports from that other module, because we're treating
all decls as part of the top-level module. This actually shows up with UIKit
and QuartzCore due to some weirdness in how the QuartzCore module is set up
(see <rdar://problem/17888079>), resulting in 'CALayer' not being visible
with just 'import UIKit'.
Workaround (this patch): treat Clang imports just like Swift imports: if the
submodule is referenced, so is the top-level module. This isn't great, but
it's not really any more awful than the rest of our Clang modules story.
<rdar://problem/17607060>
Swift SVN r20920
The corrections are:
- Change the UIFont's API from '?' to '!'. These APIs are almost never get checked.
- Change the "options" array parameter to being optional.
Swift SVN r20723
...and 'assign' and 'unsafe_unretained' as 'unowned(unsafe)', if the
property is a class type.
This isn't important for the compiler, but it is documentation for users
when they look at the generated interface for an Objective-C module.
Note that this actually produces a decl users can't yet write:
unowned(unsafe) var foo: UIView!
That's <rdar://problem/17277899> unowned pointers can't be optional.
<rdar://problem/17245555>
Swift SVN r20433
Ban use of CFRetain, CFRelease, CFAutorelease used for manual memory management as well as a bunch of other similar APIs, such as CGColorRelease.
Addresses radar://16892185
Swift SVN r19552
We still don't import the fields of unions or bitfields, but we want to at least be able to represent the types so that APIs using the types can be used from Swift. IRGen should be able to produce the correct layout for these types even if all of their fields don't get reflected into Swift.
Swift SVN r19529
...where T is the equivalent Swift function type. This gives us proper type
safety (ish) for C function pointers while still not treating them the same
as Swift closures.
If the function type is not one we can represent in Swift, we fall back to
COpaquePointer. CFunctionPointer<T> and COpaquePointer can be explicitly
constructed from one another, but do not freely convert.
<rdar://problem/17215978>
Swift SVN r19154
