The changes in #81996 fixed the response file format but failed to
actually make `line-directive` stop expanding the response files in the
compiler invocation. These changes fix that.
`line-directive` was expanding response files for the swiftc invocation,
which was causing issues on CI when the file list got too long. This
changes the script to stop expanding response files and pass them as-is
to the swiftc invocation instead. The format for the response files was
also incorrect, with each individual file being quoted, so this fixes
the CMake script generating those.
Finally, this changes `line-directive` to dump the command line on
failure.
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.
The library `six` provides compatibility between Python 2, and 3. It's no
longer necessary once we migrate of Python 2 completely.
Also remove any custom logic for Python 2 (the ones referenced by
a commentanyways).
https://bugs.swift.org/browse/SR-16025
Treat the I/O data as UTF-8 rather than the system encoding, which can
fallback to `C`, treating unicode data as ASCII. This improves the test
coverage on Linux with Python 3.
`ModuleNotFoundError` was introduced in python 3.6 as a child of
`ImportError`. However, some of the CI hosts use python 3.5. Use
`ImportError` as the filter type to be compatible with earlier python
versions.
New versions of Python warn if the literal is not escaped. Specifically:
"Support for nested sets and set operations in regular expressions as in
Unicode Technical Standard #18 might be added in the future. This would
change the syntax. To facilitate this future change a FutureWarning will
be raised in ambiguous cases for the time being. That include sets
starting with a literal '[' or containing literal character sequences
'--', '&&', '~~', and '||'. To avoid a warning, escape them with a
backslash. (Contributed by Serhiy Storchaka in bpo-30349.)"
https://docs.python.org/dev/whatsnew/3.7.html
The line directive test was using a command for one of the tests. The
command was being built as a string, instead of relaying on Python
multi-platform command building from arrays. Additionally the command
itself was being escaped with single quotes, which in Windows mean
nothing and were ending in the output of the command.
The changes switches the string building for an array, and leaves the
string building and escaping to Python. This should work in both
macOS, Linux and Windows.
This should fix the failing test in Azure.
...i.e. an actual shell-like argument list, rather than a
semicolon-separated list (CMake's internal stringification mechanism
for lists). Apart from being a little easier to read, this also works
directly with the response file support in swiftc itself now (not
depending on utils/line-directive).
(It's still not /quite/ enough to expand on a command-line, though,
since that will escape the quotes. The 'sed' command can get around
that: $(sed "s/'//g" foo.txt).)
