This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
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
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
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
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
When determining whether one imported initializer stomps on another,
use the parameter types rather than the full type. This prevents
differences in failability from causing ambiguities.
Swift SVN r21692
Map BOOL parameters, return types, and properties to swift.Bool in the Clang importer like we map NSString to swift.String. Generalize SIL's handling of type bridging to accommodate Bool bridging in addition to String bridging. Add convertObjCBoolToBool and v.v. entry points for the compiler to use to insert bridging conversions between the two types. Implements <rdar://problem/14271667>.
Swift SVN r5819
