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
