This solves deprecation warnings in build-script:
```
DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
```
This change assumes that the minimum version
of Python3 is 3.3, which has `shlex.quote`.
Since our build bots currently use 3.6 as their
Python version, we can't yet use `shlex.join`
to further simplify some of the code using
quote.
This flag is a GNU extension, and would cause misleading test failures
on other platforms where this extension is not available. However, the
necessity to switch line endings is only required on Windows when
testing. We could use sed to canonicalize line endings before comparing,
but that may cause higher amounts of filesystem traffic on Windows which
would slow down testing.
Instead, move the substitution for diff in SourceKit's lit.local.cfg up
to the top level, and conditionalize the substitution which has the flag
on Windows, but not on other platforms (where it should not be required).
Attempt to properly quote the python interpreter path in the lit
configuration. This was quoted in some places but not others. This
attempts to homogenise the path quoting.
Add a global -module-cache-path option to `sourcekitd-test` and
`complete-test` and have lit provide the default module cache in its
substitutions. Previously many tests have explicitly provided the
`%mcp_opt` option, but this is easy to forget when writing new tests.
The module cache is inserted into the compiler arguments at the
beginning so that it's still possible for a test to override it with a
per-test cache if desired.
rdar://58752842
The quoting of the sed commands was creating problems in my Windows
installation. I am unsure if the implementation of sed.exe is different
or the cmd.exe is different.
In order to avoid problems in different machines, replace the piped sed
commands into only one python script. This should be multiplatform and
should execute the same in any of them. It also remove a lot of the
extra quoting and escaping, and avoids 5 processes for only just one.
This has been an unnecessary code path for a long time now and should be removed particularly because it triggers wasteful `stat` calls.
rdar://51523161
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
LLVM's lit implementation switched to use process pools in r299775.
This exposed some pickling problems in Swift's lit files. For a function
or class to be pickle-able, it has to be in the top-level of a real
Python module.
* The SwiftTest lit format class was embedded in the lit.cfg file, so
I moved it out to a separate Python file.
* The inferSwiftBinary function was being stashed in the
config.inferSwiftBinary field and later used to find tools for SourceKit
testing. I moved the config settings for those tools into the top-level
lit.cfg file. I expect this will cause warnings about them not existing
in some cases, but that should be fairly harmless. Maybe someone can
come up with a better solution later.
* The config.substitutions for SourceKit's lit.local.cfg was storing a
reference to an embedded sed_clean function, which just returned a
constant string. I changed the function to be a string, using Python's
raw string feature to avoid the problems that likely led to it being a
function in the first place. (Just guessing.)
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
