`remote-run` should look in the environment for input/output paths as
well as considering command line arguments.
With this change, `test/Runtime/Paths.cpp` should work for remote testing
and device testing.
rdar://106294557
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Not only does this give us a huge speed-up, it also works around a problem
where sftp doesn't always update the modification time, which causes random
test failures.
rdar://88179140
Make `remote-run` be compatible with python 2 and python 3. The changes
are:
- replace `viewitems` with `items`
- replace `viewvalues` with `values`
- replace `viewkeys` with `keys`
- replace `haskey` with `in`
Not all the tests are possible to run on Windows since they expect a
Unix-like shell environment. However, the rest of the tests can be
accommodated. This actually found an issue in the implementation.
Since the implementation assumes the target is POSIX/Unix-y, we should
use posixpath rather than os.path which uses the host's path style.
Really we ought to clear out "%t*", but running wildcards with 'rm'
scares me a little too much for that. This still fixes a handful of
tests that were relying on %t being an empty directory.
Note that this doesn't interfere with generated files persisting
between %target-run invocations; they'll be downloaded and then
re-uploaded as long as they're mentioned in the invocation.
This is mostly important to allow remote-run to be used to upload
files generally, while still using the same interface and arguments
that will be used to actually run executables.
(instead of locally)
The primary use case I'm looking at is easier testing across macOS
versions, but it could also be used for cross-compilation tests in
general (someday).
