[llvm-dev] phab unit tests + libcxx tests w/concurrency
Brian Cain via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 25 07:41:40 PST 2020
I think it may make sense to segregate the libcxx lit tests that expect a
task to be completed in a particular threshold. Either they should move to
the llvm test-suite or they should be under a feature guard that omits them
from the default test target. These tests are sensitive to the load and/or
capability of the target on which they're tested. I appreciate that it's
likely impossible to write a noninteractive test for these library
concurrency features that aren't designed with some kind of thresholds.
I have an "innocuous" change that was automagically tested (pre-merge!) via
phabricator -- https://reviews.llvm.org/D75085 -- but it triggered a test
failure in one of the "thread_mutex_class::try_lock.pass.cpp" tests.
It's great and super convenient to have this test facility and I'm pretty
sure I opted-in to it. I think it would be/would have been nice for it to
be integrated with github PRs, but this seems functionally pretty close.
Having this pre-merge check helps buoy confidence in my change - that it's
less likely to cause a buildbot to trigger. We should strive to eliminate
false signals from this test suite. Either the test suite should omit
check-cxx (not my preference) or the cxx tests must be descoped to reliably
passing ones. Or maybe the test infrastructure could be
partitioned/dedicated such that it's very unlikely to have false failures
like this.
Also, thanks again to the teams who work on providing testing features like
this, it's a step in the right direction.
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200225/b3982a0c/attachment.html>
More information about the llvm-dev
mailing list