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
-enable-source-import doesn't play nice with debug info, and we want to be
able to run all tests with -g added. The last few tests that require
-enable-source-import could be built with --no-debug-info, or however we
end up spelling that.
rdar://problem/18140021 (most of it)
Swift SVN r22742
...unless they are in a private class.
Consider this scenario:
class Base {
func foo() -> Base { ... }
}
class Sub : Base {
private override func foo() -> Sub { ... }
}
class Grandchild : Sub {
override func foo() -> Base { ... }
}
Because Grandchild can't see Sub, its override of foo() looks perfectly
reasonable...but now Sub's expectations for foo() have been broken.
Swift SVN r19769
Emit ObjC stubs and categories for methods defined in extensions of ObjC-compatible classes. This makes extensions of ObjC classes available to ObjC in statically compiled code. For immediate-mode code we'll still need to dynamically register extension methods using the ObjC runtime.
Swift SVN r4149
