This commit is not meant to completely test update-checkout, but rather create
some scaffolding for testing update-checkout so we can create starter bugs to
fill out the rest of the functionality. Once we have enough testing in place, we
can start refactoring/simplifying update-checkout.
Design
------
This is just a standard python unittest test suite except that the tests expect
an environment variable (UPDATECHECKOUT_TEST_WORKSPACE_DIR) to be set that
specifies the directory that the unittests have for creating mock git repos
during setup/teardown. lit invokes the test by calling the unittests with the
environment variable set to the appropriate temporary directory.
In this temporary directory, each test creates a pristine set of "fake" remote
repos and a test-config.json file that can be passed to update-checkout to work
with these "fake" remote repos. This allows each test that we write to test
various update-checkout functionalities against a pristime set of git repos. I
choose the git clone test, just b/c it was really simple.
NOTE: One can also run the tests locally using the script
test_update_checkout.sh that uses /tmp/workspace as the workspace directory.
This enables mocking testing to work (otherwise we would create repos in
SWIFT_SOURCE_ROOT). SWIFT_SOURCE_ROOT is the default value so nothing changes
unless one specifies the argument explicitly.
Admit defeat and realize that one simply cannot win against Windows. Use
the pattern with both separators in the tests and remove the hack in
PathSanitizingFileCheck because it created false positives, some of them
could not have been easily fixed.
Sadly lit substitutions or other tricks in lit.cfg will not work,
because CHECK lines are not processed by lit, but by FileCheck.
[darwin][build] Copy the libclang_rt.{ios/tvos/watchos}.a from toolchain to the build dir so that swift-clang can use them when building for ios/tvos/watchos
[Build System: build-script] Update the --stdlib-deployment-targets flag to no longer append from multiple uses, instead use the standard last-wins strategy.
There were several Unix specific things in the ParseableInterface tests:
the Bash subcommand was used, a Python tool was invoked without an
explicit interpreter, and Unix path separators are used in CHECK lines.
The Bash subcommand is replaced by a Lit substitution. Both swiftmodule
and swiftdoc had substitutions, so swiftinterface gets one which should
about the subcommand.
The Python tool is invoked with an explicit interpreter.
The Unix paths, instead of adding the ugly {{\\|/}} pattern everywhere
are fixed in the PathSanitizing tool instead, that gets a new capability
in Windows compatibility mode where all the Windows path found in the
input are transformed into Windows path with only forward slashes (Unix
slashes) in the output, which can be checked textually against the CHECK
lines.
...by crawling it and looking for module interfaces. This is the tool
Apple is using for the "prebuilt-modules" directory in the toolchain
in Xcode.app, which avoids even a first-use cost for importing modules
from Apple SDKs as long as the SDKs haven't changed. We've been
landing changes to support this model on the compiler side, so the
tool to generate the "prebuilt" compiled modules belongs in the
compiler repo too. (In theory this could be used with open-source
toolchains as well, or for alternate SDKs.)
For invalid code, lexer is forgiving enough to allow single quote '\'' as the starting point
of string literals. Later, parser assumes the string literals are always using double quote "\"", and passes
such knowledge to SwiftSyntax side, leading to the round-trip failure we observed in the radar.
This commit fixes the issue by introducing another token kind for single quote.
rdar://51071021
The tests need to change the working directory when executing on Windows
as RPATH is not supported on the platform. The current working
directory gets precedence over `PATH` for library lookup. This allows
the last of the Evolution tests pass on Windows.
- Forward several environment variables to the test environment because
Windows uses them to inform the processes about things like the number
of processors and the architecture.
- Normalize some literal Unix paths to be the same as the results in
Windows, that will have forward slashes and the drive letter.
- Skip some test that use build-script-impl and tests that check for
files being executable (everything is executable in Windows).
- Don't use the owner and group arguments for tar on Windows.
- Hide the stderr output of which. In Windows it prints the full PATH in
case of failures, which is disrupting.
- Quote many paths in Windows in the output of build-script results.
- Provide a version of mock-distcc that can be executed in Windows. The
raw Python script cannot.
- Change the expected results for clang/clang++ to the right values in
Windows (clang-cl in both cases).
Otherwise, we will need to reconfigure when someone uses the build vs test
preset. Because the reconfiguring forces a rebuild, this is unfortunate.
Luckily, we want to make it so we always only build stdlib tests, so this works
around the problem.
Windows does not support the concept of RPATH. As a result, we must
change the working directory for the test. This extends the support
for the tests to work with PE/COFF on Windows. Use the newly minted
`self.triple` property to drive the host detection. This means that
the test coverage on Windows is able to test most of the resilience
functionality.
With the previous commit, one can choose when to reconfigure. I have noticed
that when we reconfigure the preset, we always rebuild. So having reconfigure by
default messes with the experience of using the preset.
