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.
lldb-dotest does not forward the arguments from DOTEST_EXTRA properly.
For now, just build the lldb-dotest target to ensure the cmake build has
the right dependencies built. Invoke dotest.py manually as before.
Using lldb-dotest to drive testing solves the short-term problem of
there being missing test dependencies when we invoke dotest.py for cmake
builds.
Long term, we really want to delete as much lldb-specific logic from
build-script as possible and replace all of it with a single call to
lldb-dotest.
Even with this first cut, there are some nice simplifications
(build-script no longer needs to know how to find an out-of-tree
debugserver, etc).
* LLDB assertions are on by default, like swift assertions
* LLDB assertions can be enabled/disabled globally with the --assertions
and --no-assertions options
Partially addresses: rdar://38524846
The lldb bots should run the full lldb test suite, not just the tests
reserved for pull-request testing.
This does not affect PR testing.
rdar://38462589
This adds two flags to the build script to enable/disable assertions in
llbuild: --llbuild-assertions, --no-llbuild-assertions
The default value is taken from the global assertions flag.
Will be used to verify that withoutActuallyEscaping's block does not
escape the closure.
``%escaping = is_escaping_closure %closure`` tests the reference count. If the
closure is not uniquely referenced it prints out and error message and
returns true. Otherwise, it returns false. The returned result can be
used with a ``cond_fail %escaping`` instruction to abort the program.
rdar://35525730
The existing libSyntax infrastructure uses external python
dictionaries to share logic between C++ and Swift implementations.
This patch teaches trivia kinds to adapt to this infrastructure
as well.
The CMake support in llbuild is finding the compiler in the system
instead of the build products. This causes build errors if Swift is old
on a system.
Sometimes it is really useful to be able to dump the disassembly from lldb into
a file so that one can work with the disassembly in an editor. The disassemble
command in lldb does not provide such facility today. So this lldb function in
the lldb toolbox provides such a facility.
