TBD generation is not constrained to Darwin and it trips on the linker
synthetic `__ImageBase`. XFAIL this until the TBD generation is either
constrained or is taught to ignore the synthetic. This should
temporarily allow us to enable validation tests on Windows.
This just uses the `%target-build-swift-dylib` instead of
`%target-build-swift` substitution along with `%target-library-name` to
ensure that we are target independent.
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
Test requiring ASan are currently failing on internal bots that test
back deployment because of a test infrastructure problem with ASan bac
deployment.
Mark those tests as unsupported for remote_run (which is currently only used
for those back-deployment tests) until we can address the underlying issue.
The naming convention is different on Windows than on Unix-like
environments. In order to follow the convention we need to substitute
the prefix and the suffix. Take the opportunity to rename the
`target-dylib-extension` to the CMake-like variable
`target-shared-library-suffix` and introduce
`target-shared-library-prefix`. This helps linking the test suite
binaries on Windows.
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
Finally, remove the parent type metadata argument from type
constructors.
Now that type constructors don't take a parent metadata pointer,
we can hit some asserts concerning type constructors that do not
have any parameters. This happens when you define a concrete type
in a fully-constrained extension of a generic type.
A more efficient ABI would use concrete type metadata for these
cases, but that would be a bigger change that we can do later, so
for now just relax these assertions.
This resolves a runtime crasher since a circular metadata case is
no longer circular. I renamed the crasher to reference the more
specific radar since the more general issue of circular metadata
is still unresolved.
Investigating a problem with execution tests on other platforms
when building multiple dylibs and an executable that builds them.
rdar://problem/27620565
There wasn't an execution test involving #dsohandle, so add one here.
Also, the DSO handle coming from different modules should never be
the same.
rdar://problem/26565092
This is the Linux equivalent of 3731a2ff0. There's probably a way to
merge them into one file cleanly, but the extra linker args on OS X
make it a little tricky. I'm deciding not to worry about it right now.
...when interpreting. Otherwise, the script may depend on library X, which
depends on library Y, where library Y is a standard Swift library, located
in lib/swift/$PLATFORM/.
Finishes rdar://problem/23588774
...as described in rdar://problem/23588774. We don't really have a good way
to make this test cross-platform as such, but I'll add a Linux version soon.
