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
