[Lldb-commits] [lldb] [lldb-dap] Refactor lldb-dap event handling. (PR #139669)

[John Harrison via lldb-commits]

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