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
That's DYLD_LIBRARY_PATH on OS X and LD_LIBRARY_PATH on Linux for -L,
and DYLD_FRAMEWORK_PATH on OS X for -F.
Note that this commit doesn't actually include the setenv calls yet, so an
end-to-end test is coming in the next commit.
Part of rdar://problem/23588774
In the interactive driver, disable a bunch of flags that only work with
swiftc driver (NoInteractiveOption => disallowed, doesn't show up in
help when invoked as 'swift'). Also move some options to HelpHidden
(hidden from -h in both 'swift' and 'swiftc') that we don't need to
advertise.
Swift SVN r20780
This flag is now obsoleted by the interactive driver and simply
complicates understanding the command-line parsing. Making it an error
to force users to move also allows us to reuse the flag in the future if
we like.
Swift SVN r20641
This makes the command line interface to 'swift' the same as what was
previously in 'swifti', and removes the staging symlink.
For posterity, the command line behaviour for 'swift' is now:
* `swift` -> start the repl
* `swift script.swift` -> run script.swift (the old -i mode)
* Any arguments after the input file are forwarded to the script as
Process.arguments
* A shebang line is something like #!/usr/bin/xcrun swift
The batch compiler 'swiftc' behaves much like the old 'swift'
executable, but without the interactive bits now in 'swifti'.
<rdar://problem/17710788>
Swift SVN r20540
Most of the tests just got moved to swiftc, but some of them were
duplicated to apply to both swiftc and swift. A handful still use the
existing 'swift' because they are for the existing '-i' syntax.
Note: this means config.swift_driver now uses the staging symlink
'swifti'. The only thing preventing us from dropping the 'i' and getting
rid of the old interface is that Xcode hasn't moved to swiftc yet
<rdar://problem/17769327>.
Swift SVN r20467
For now, keep 'swift' the same and put all the interactive driver
changes under 'swifti'. When these are in good shape, I will remove
swifti and make 'swift' the interactive driver as discussed.
Swift SVN r20359
The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
