ashgti wrote: > I believe you, but I don't understand. Since this restricts the set of > possible message orderings (does it?), I would naively expect that a test > which worked previously (with the wider set of orderings) would continue to > work afterwards. > > The only way I can imagine this not being true is if the tests weren't 100% > correct (i.e., they were flaky), but whereas previously the "bad" case would > happen 0.1% of the time, this patch now makes it the 100% case. And it's > easier to make the test always expect the (previously) bad case than it is to > accept all of the technically legal orderings. Is that's what happening? > Maybe an example would help...
I think our tests are not fully specifying their expected state. For example, lldb/test/API/tools/lldb-dap/console/TestDAP_console.py `TestDAP_console.test_diagnositcs` was performing an evaluate and then using `get_important` to fetch output events with category 'important'. With the change, the `important` output was always coming after the request was handled. I updated the test to use a `self.collect_important` instead of `get_important`. Previously, this could have been emitted while the request was being handled, but now the output would only ever be emitted after the request handler is finished. https://github.com/llvm/llvm-project/pull/139669 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
