This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
When the swift_bridged_typedef attribute is present on a typedef,
import the underlying type as bridged (e.g., String) rather than as
its unbridged type (e.g., NSString).
Fixes rdar://problem/39497900.
conversions that reverse an implicit conversion done to align
foreign declarations with their imported types.
For example, consider an Objective-C method that returns an NSString*:
- (nonnull NSString*) foo;
This will be imported into Swift as a method returning a String:
func foo() -> String
A call to this method will implicitly convert the result to String
behind the scenes. If the user then casts the result back to NSString*,
that would normally be compiled as an additional conversion. The
compiler cannot simply eliminate the conversion because that is not
necessarily semantically equivalent.
This peephole recognizes as-casts that immediately reverse a bridging
conversion as a special case and gives them special power to eliminate
both conversions. For example, 'foo() as NSString' will simply return
the original return value. In addition to call results, this also
applies to call arguments, property accesses, and subscript accesses.
(and similar for flag_enum)
This commit prepares the importer for a world in which NS_ENUM and
NS_OPTIONS have adopted the new Clang attributes 'enum_extensibility'
and 'flag_enum', but API notes are used to reverse the effect. Without
this there would be no transition path for adopting the standard Cocoa
macros, which have applied unconditionally up to now.
rdar://problem/18744821
For every struct type for which the frameworks provides an NSValue category for boxing and unboxing values of that type, provide an _ObjectiveCBridgeable conformance in the Swift overlay that bridges that struct to NSValue, allowing the structs to be used naturally with id-as-Any APIs and Cocoa container classes. This is mostly a matter of gyb-ing out boilerplate using `NSValue.init(bytes:objCType:)` to construct the instance, `NSValue.objCType` to check its type when casting, and `NSValue.getValue(_:)` to extract the unboxed value, though there are a number of special snowflake cases that need special accommodation:
- To maintain proper layering, CoreGraphics structs need to be bridged in the Foundation overlay.
- AVFoundation provides the NSValue boxing categories for structs owned by CoreMedia, but it does so using its own internal subclasses of NSValue, and these subclasses do not interop properly with the standard `NSValue` subclasses instantiated by Foundation. To do the right thing, we therefore have to let AVFoundation provide the bridging implementation for the CoreMedia types, and we have to use its category methods to do so.
- SceneKit provides NSValue categories to box and unbox SCNVector3, SCNVector4, and SCNMatrix4; however, the methods it provides do so in an unusual way. SCNVector3 and SCNVector4 are packaged into `CGRect`s and then the CGRect is boxed using `valueWithCGRect:`. SCNMatrix4 is copied into a CATransform3D, which is then boxed using `valueWithCATransform3D:` from CoreAnimation. To be consistent with what SceneKit does, use its category methods for these types as well, and when casting, check the type against the type encoding SceneKit uses rather than the type encoding of the expected type.
We wouldn't care except that its constants are named TRUE and FALSE and
that shows up in the global namespace.
rdar://problem/20943410
Swift SVN r29651
When -enable-simd-import is active, if we encounter a vector type, try to load the SIMD Swift module, and if successful, map float, double, and int vectors to SIMD.{Float,Double,Int}N types if they exist.
Swift SVN r27367
typedef unsigned long ByteCount;
typedef unsigned long ItemCount;
Both of these are still in use by CoreMIDI, but we don't have a reason to
keep them distinct in Swift.
rdar://problem/19939552
Swift SVN r25529
We certainly can't import them as stored properties, and it's too late to try to bridge them as computed property, so restore the old behavior of importing them as unbridged object types. The types still come in as strong managed reference types, which is still wrong, but seems to be right enough for Khan Academy and potentially other existing apps for now, and I don't want to introduce additional source-breaking changes and instability this late in the game. Fixes rdar://problem/19789023, leaving rdar://problem/19790608 to be done when we can afford more churn.
Swift SVN r25158
This affects the MacTypes.h header in the Darwin module as well as the
CarbonCore and OSServices sub-frameworks of the CoreServices framework.
API hidden in this way can still be accessed through qualified lookup
in case it's really needed, but will not appear in the module interface
or in code completion.
This is a hack, and it would be nice to remove it if/when all of this API
is officially marked as deprecated. I did check with Nick for MacTypes.h
and Chris Linn from CoreServices that this was a reasonable action to take.
rdar://problem/16806148
Swift SVN r24424
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
Introduce the UIApplicationMain attribute, and check that it's only applied to nongeneric classes that conform to UIApplicationDelegate.
Swift SVN r18048
...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
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
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
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
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
