[libcxx-dev] phab unit tests + libcxx tests w/concurrency

Brian Cain via libcxx-dev libcxx-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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200225/b3982a0c/attachment.html>

More information about the libcxx-dev mailing list