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
Some AST nodes and SIL instructions need to reference conformances for a
particular type. If that type was imported from Clang, however, the
conformance may not exist when the AST node or SIL function gets deserialized
later. The SIL case is the problem case: fragile SIL code may contain a
reference to a conformance never mentioned in the AST of the code being
compiled, and since conformances are synthesized on demand during type-checking,
this will lead to a crash. SIL deserialization isn't supposed to be doing
work on its own (though it ~can~ import new Clang decls at the moment), so
the best answer is to serialize the conformances directly, like we would with
specialized or inherited conformances.
We can probably do better here in the long run (we don't even unique
conformances like this within a module), but this should at least handle the
immediately known problem cases.
rdar://problem/18669402
Swift SVN r22857
