This test uses %swiftc_driver_plain instead of %swiftc_driver or
%target-build-swift because it's testing what the driver does when
invoked with no -swift-version argument, but that means we have to
manually set up things like a module cache path. This will then fail
if it's the first Driver test run in a clean build directory (because
of where lit.py decides to put temporary files).
rdar://problem/38354843
Put in a general mechanism for mapping user-specified "compatibility
versions" to proper "effective versions" (what #if and @available
checking should respect). This may still be different from the
intrinsic "language version"; right now master is considered a "3.1"
compiler with a "Swift 4 mode", and we plan to ship a "4.0" compiler
with a "Swift 3 mode" that will have a version number of something
like "3.2".
rdar://problem/29884401 / SR-3791
The driver exits out early if there's no stdlib for the target you're
compiling for, and these tests didn't pass a target for one reason or
another.
rdar://problem/29173390
This allows us to run our entire test suite (well, okay, just
invocations of swift/swiftc and swift-ide-test) under Swift 3 mode or
Swift 4 mode, which will be more important as the two modes diverge.
The default is Swift 3 mode for now, which matches the behavior before
this patch (because the master compiler still calls itself 3.0).
Individual tests can still use "-swift-version 3" to override the mode
set by lit, but if an entire test requires Swift 3 or Swift 4, there's
also a new test feature "SWIFT_VERSION=3" or "SWIFT_VERSION=4".
However, if you /do/ need to override or restrict the version, you
should also add a test for the "other" version as well, unless it's
part of the Compatibility suite or otherwise specifically testing
-swift-version-related functionality.
