lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
Here we fix a few portability issues affecting running the validation tests on OpenBSD. The remaining failures will be dealt with separately.
1. In the `rth` tool, ensure `-z origin` is specified to the linker when
using `$ORIGIN`, as required on this platform.
2. Explicitly set the rpath in the `dsohandle-multi-module` execution
test, since the test uses built dynamic libraries during the test.
3. Erase the environment variable instead of using `env -u`, the latter
of which is not portable.
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.
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".
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
