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.
