When running the tests with a toolchain built with the "early swift
driver", we would incorrectly process the command line, losing the empty
string argument to `-sdk` which would then incorrectly process the
remainder of the command line. This allows most of the remaining tests
to pass with the early swift driver on Windows (assuming that the paths
are adjusted properly).
This makes it easier to make interpreter modes behave differently from
compilation modes. Obviously that's a trade-off, since the two modes also
share plenty, but given how few of the existing CompileJobAction checks had
to be modified for the new InterpretJobAction, I think this is the right
way to go.
Groundwork for setting [DY]LD_LIBRARY_PATH ahead of time when invoking the
interpreter, which is rdar://problem/23588774.
There are two valid values for this: 'swift' and 'swiftc'. This flag must be
specified as the first option; otherwise, it will be ignored. This flag allows
the caller of the driver to force 'swift' to behave as 'swiftc', or vice versa,
and is useful in situations where the name of the executable cannot be changed.
Swift SVN r20656
