labath added a comment. In D99497#2656600 <https://reviews.llvm.org/D99497#2656600>, @clayborg wrote:
> In D99497#2656502 <https://reviews.llvm.org/D99497#2656502>, @labath wrote: > >> Isn't there a better way to ensure synchronization here? Maybe, executing >> some command (setting a breakpoint, for instance), that will ensure that all >> symbols have been parsed? > > That is what I attempted do in the test: set a breakpoint at 'main' which > should trigger all of the needed events. Then we run to a breakpoint and hit > it. and after we hit this breakpoint, then we check the progress events. Ok, I see what you mean. I looked (briefly) at the code, and my impression is that this dance will ensure that the progress events get /sent/, but they will not ensure that they are actually receieved/processed (as the receiving end is completely asynchronous). The next question then becomes: is that intentional? If it is, then a delay is indeedall we can do (and I suspect we might need even more than 1s to sufficiently safe). Having progress events come after the operation that uses their results completes would be a bit weird, though it probably won't cause much problems in practice. This situation actually reminds me of what we do with inferior stdout. That also used to be fully asynchronous (on several levels), but that ended up causing problems (for tests, at least), as we would try to assert that the inferior has written something after it hits a breakpoint, but that text would still be in flight. We solved that by explicitly flushing any pending output before sending the "stopped" event. One could imagine doing something similar in vscode as well -- before replying to a command (in this case, breakpoint set), check the progress listener, and flush any pending events. > One thing we could do to figure things out would be to dump the vscode.txt > file for this test into the failing test. This would allow us to see what the > packets looked like when a test fails. Is there a cleanup function or > something we can do in the VS code tests that allows a test case to know it > has an error and add some stuff to the test suite output?? There are several ways to do that. The simplest (and most useful, I think) would be to just stream the messages (both sent and received) to stdout if `self.traceOn()` is true. I don't think it will help much in this case, but it could be pretty useful in the future. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99497/new/ https://reviews.llvm.org/D99497 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
