If a Lit test fails, re-run it 5 times to increase our odds of
detecting non-determinism early. If the test turns out to
be flaky, it will fail and be reported as a FLAKYFAIL to stress the
encountered non-determinism.
Long tests and tests in `test/Interop/Cxx` are deliberately exempted
from retries to avoid timeouts and unreasonable spikes in turnaround
time.
The python-lint test was failing with:
./test/swift_test.py:35:1: W293 blank line contains whitespace
./test/swift_test.py:36:80: E501 line too long (87 > 79 characters)
./test/swift_test.py:37:80: E501 line too long (84 > 79 characters)
./test/swift_test.py:40:80: E501 line too long (82 > 79 characters)
./test/swift_test.py:41:26: E701 multiple statements on one line (colon)
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.)
