* Remove support for linking arclite
Darwin no longer uses arclite and it's no longer distributed
in the macOS SDKs.
This leaves the options -link-objc-runtime and -no-link-objc-runtime
in place, but strips out all the logic that actually used them.
* Remove a dead function
* Warn if `-link-objc-runtime` is used
* Update tests to not look for arclite library
* Add an explicit test for the deprecation warning
* Move the macOS-only -link-objc-runtime test to a separate test file
The Swift driver (swift/swiftc) is supposed to always be used with an
accompanying SDK, which it derives from the environment. Our test
infrastructure was clearing out this SDK, making it deviate from the
normal operating environment unnecessarily. Switch to providing the
SDK used for building the standard library, which provides a
more-consistent test environment, and tag the few places in tests
where we have explicit dependencies on "no SDK."
Previously, with the tool and option both included in the suggestion, it
was not immediately clear which of the two was being suggested as a fix.
Resolves SR-5677.
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
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
