This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
We have a few serialization bugs, inconsistent rules and ugly workarounds. We
are planning to get this right as part of the work on resilience. Until we nail
down the serialization rules and fix the implementation I am disabling two tests
that prevent us from moving forward with the work on the optimization pipeline.
The plan is to enable SIL verifications as soon as possible.
rdar://23805004
The commit that added the module verification to the pass manager breaks our linux build
with the following message:
SIL verification failed: vtable entry for #_NativeSetStorageOwner.init!initializer.1 must be ABI-compatible
It looks like all of the SIL/parse_stdlib_XXX.sil tests are failing.
This reverts commit aafc973968.
This commit makes the pass manager verify the module that it needs to handle
before the transformations start. This verification only happens in debug mode.
The new assertion catches a few errors in our test suite. I filed rdar://23667534
and disabled the failing deserialization tests.
rdar://23667534
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
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
