This allows us to run our entire test suite (well, okay, just
invocations of swift/swiftc and swift-ide-test) under Swift 3 mode or
Swift 4 mode, which will be more important as the two modes diverge.
The default is Swift 3 mode for now, which matches the behavior before
this patch (because the master compiler still calls itself 3.0).
Individual tests can still use "-swift-version 3" to override the mode
set by lit, but if an entire test requires Swift 3 or Swift 4, there's
also a new test feature "SWIFT_VERSION=3" or "SWIFT_VERSION=4".
However, if you /do/ need to override or restrict the version, you
should also add a test for the "other" version as well, unless it's
part of the Compatibility suite or otherwise specifically testing
-swift-version-related functionality.
- Update the Pygments lexer we use for parsing Swift-like code.
- State more explicitly which highlighting should be used in which
code blocks.
- Disable highlighting altogether in certain cases (such as SIL.rst,
which has equal amounts grammar and SIL excerpts).
This should fix the warnings-as-error issues coming from Sphinx > 1.3.4.
Based on a patch by Jeremy Fergason!
https://bugs.swift.org/browse/SR-620
'%FileCheck' removes absolute paths of the source and build directory
from the input. Overwhelming majority of tests don't intend to match
these paths.
Also add a substitution '%raw-FileCheck' that does not sanitize the
input.
Cygwin and MinGW should use the autolink feature in the sameway of Linux
due to the linker's limit. Now swift-autolink-extract recognizes the
COFF format file for Cygwin/MinGW.
Removing an abstraction boundary also allowed me to fix a bug where we
could not run long tests in optimized mode, which prevented us from
being able to mark executable tests as long.
* The behavior of `build-script -t` is unchanged.
* `build-script -T` continues to run primary and validation test suite,
but without the long tests.
* `build-script --long-test` runs just the long tests.
* `build-script -T --long-test` runs all tests.
Add a test feature flag static_stdlib, which is enabled if the user
builds the static libraries.
We also add the substitution %target-static-stdlib-path which gives the
path of the static stdlib.
These features allow testing specifically for the static standard
library.
Contributors likely won't need to invoke CMake directly in order to run the test suite. As such, the current testing documentation is a little misleading: it jumps into a detailed explanation of the `check-swift` family of targets, even though those are abstracted away via the build script. For example, I remember when I first read this document, I spent 20 minutes searching in vain for a build executable named `check-swift`.
Instead, change the wording to make it clear that `utils/build-script` is the best way to run the tests. For those interested in **how** the tests are executed, show an example of a CMake command that runs them.
Add explanations for lit substitutions marked as "FIXME" in the testing
documentation.
- Place all `%target-*` substitutions in the same section of the
documentation.
- Remove substitutions that are no longer available or in use, such as
`%llvm-opt` and `%leaks-runner`.
- Use uniform spacing between all substitutions bullet points.
