Stress tests are, by definition, stressful. They intentionally burn a
lot of resources by using randomness to hopefully surface state machine
bugs. Additionally, many stress tests are multi-threaded these days and
they may attempt to use all of the available CPUs to better uncover
bugs. In isolation, this is not a problem, but the test suite as a whole
assumes that individual tests are single threaded and therefore running
multiple stress tests at once can quickly spiral out of control.
This change formalizes stress tests and then treats them like long
tests, i.e. tested via 'check-swift-all' and otherwise opt-in.
Finally, with this change, the CI build bots might need to change if
they are still only testing 'validation' instead of all of the tests.
I see three options:
1) Run all of the tests. -- There are very few long tests left these
days, and the additional costs seems small relative to the cost of
the whole validation test suite before this change.
2) Continue checking 'validation', now sans stress tests.
3) Check 'validation', *then* the stress tests. If the former doesn't
pass, then there is no point in the latter, and by running the stress
tests separately, they stand a better chance of uncovering bugs and
not overwhelming build bot resources.
The Swift build system does not generate DWARF symbols in the unittests build
directory. For build systems that do, however, files would be generated with
the test suffix "Tests". These need to be excluded because otherwise
`lit.formats.GoogleTest` tries to execute them.
Running the Python style guide checker
[`pep8`](https://pypi.python.org/pypi/pep8) on the Python code headers
in this repository results in the following error being emitted:
$ pep8 utils/build-script
utils/build-script:1:1: E265 block comment should start with '# '
utils/build-script:3:1: E266 too many leading '#' for block comment
utils/build-script:5:1: E266 too many leading '#' for block comment
utils/build-script:6:1: E266 too many leading '#' for block comment
utils/build-script:8:1: E266 too many leading '#' for block comment
utils/build-script:9:1: E266 too many leading '#' for block comment
utils/build-script:11:1: E265 block comment should start with '# '
utils/build-script:11:80: E501 line too long (80 > 79 characters)
The problem is that the code header used in most Python files in the
repository:
1. Do not place a space in between `#` and the rest of the comment.
2. Contains some lines that just barely exceed the recommend length
limit.
In addition, not all code headers in the repository follow the same
template.
This commit moves all Python code headers to the following template:
# subfolder/file_name.py - Very brief description -*- python -*--
#
# This source file is part of the Swift.org open source project
#
# Copyright (c) 2014 - 2015 Apple Inc. and the Swift project authors
# Licensed under Apache License v2.0 with Runtime Library Exception
#
# See http://swift.org/LICENSE.txt for license information
# See http://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
#
# -----------------------------------------------------------------------------
#
# This file contains stuff that I am describing here in the header and will
# be sure to keep up to date.
#
# ----------------------------------------------------------------------------
We were never in this situation. For future reference, there are
two ways to use lit manually:
% lit.py $BUILD/swift*/test-macosx-x86_64/$TESTS
% lit.py --param swift_site_config=$BUILD/swift*/test-macosx-x86_64/lit.site.cfg test/$TESTS
The latter is more verbose, but lets you point at real test files in the
source directory instead of pretending they exist in the build directory.
There are probably still further improvements to be made here.
(P.S. I suggest using -sv if running lit from the command line.)
Swift SVN r31647
swift_getGenericMetadata. Mostly ripped off clang's
support for same. I did not feel confident in pulling
over the CMake equivalents, so someone else will need to.
Swift SVN r2982
