...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
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
This makes categories of NSString, NSArray, and NSDictionary available
on String, Array, and Dictionary. Note that we only consider
categories not present in the Objective-C Foundation module, because
we want to manually map those APIs ourselves. Hence, no changes to the
NSStringAPI. Implements <rdar://problem/13653329>.
Swift SVN r18920
These are too close to "true" and "false" for comfort; they add confusion and
mess up code completion. If the names appear in other contexts, though (such
as enumerator names), we should still bring them through.
<rdar://problem/17080279>
Swift SVN r18670
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
