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.
LD_LIBRARY_PATH is one of the few environment variables the LLVM 'lit'
tool /doesn't/ strip out, presumably because on some Linux systems
it's necessary to run some of the built products being tested.
However, the Swift driver also uses LD_LIBRARY_PATH when providing -L
options to the script interpreter on Linux. Weaken some of our tests
when there's an LD_LIBRARY_PATH in the environment.
(There are similar environment variables on OS X, but we don't have to
do anything special there because lit /does/ strip those out. This is
presumably okay because all of LLVM's load-time dependencies on OS X
are in standard system locations.)
https://bugs.swift.org/browse/SR-813
test/Driver/environment.swift is trying to test that the driver can set
environment variables that the frontend will use, but the only environment
variables we set are ones that are blocked by OS X's "System Integrity
Protection" feature when invoking a restricted binary---such as /bin/sh.
We could compile a tiny app that calls getenv, but that's a bit heavy for
this test. Instead, just limit it to non-OS-X hosts.
test/Driver/options-interpreter.swift is testing the effect of the /user/
setting the same sensitive environment variables. In this case, we want to
make sure we're calling the Swift driver directly so that we don't run afoul
of the same limitations environment.swift was seeing.
Fixes rdar://problem/23771412 (which is just about re-enabling these tests).
I filed this under Radar rather than bugs.swift.org because it's /only/ our
CI system that's failing, and external contributors have no insight into
that anyway. Hopefully I'll be able to get to the bottom of this soon.
...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
Implementing this for the general case either requires duplicating the
existing environment, or modifying TaskQueue to support "extra environment"
settings. Since we don't actually have any use cases for this yet, I'm
leaving it unimplemented for now.
Rest of rdar://problem/23588774
