[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[lldb] Add assertState function to the API test suiteAdd a function to make it easier to debug a test failure caused by anunexpected state.Currently, tests are using assertEqual which results in
[lldb] Add assertState function to the API test suiteAdd a function to make it easier to debug a test failure caused by anunexpected state.Currently, tests are using assertEqual which results in a cryptic errormessage: "AssertionError: 5 != 10". Even when a test provides a messageto make it clear why a particular state is expected, you still have tofigure out which of the two was the expected state, and what the othervalue corresponds to.We have a function in lldbutil that helps you convert the state numberinto a user readable string. This patch adds a wrapper aroundassertEqual specifically for comparing states and reporting better errormessages.The aforementioned error message now looks like this: "AssertionError:stopped (5) != exited (10)". If the user provided a message, thatcontinues to get printed as well.Differential revision: https://reviews.llvm.org/D127355
[lldb] Skip more tests that don't make sense to run remotelySkip another batch of tests that don't really make sense to runremotely.
[lldb] Replace asserts on .Success() with assertSuccess()Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).* `assertSuccess` prints out the error's message
[lldb] Replace asserts on .Success() with assertSuccess()Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).* `assertSuccess` prints out the error's message* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge* `assertSuccess` statements are more succinctDifferential Revision: https://reviews.llvm.org/D119616
To avoid the obvious problem, use a different port...There's another test that opens an hard-coded port to talk to debugserver(TestPlatformSDK.py). Make sure this port and the one in that othert
To avoid the obvious problem, use a different port...There's another test that opens an hard-coded port to talk to debugserver(TestPlatformSDK.py). Make sure this port and the one in that othertest are different to avoid that potential conflict.
Fix a bug in Launch when using an async debugger & remote platform.We weren't setting the listener back to the unhijacked one in thiscase, so that a continue after the stop fails. It thinks the p
Fix a bug in Launch when using an async debugger & remote platform.We weren't setting the listener back to the unhijacked one in thiscase, so that a continue after the stop fails. It thinks the processis still running. Also add tests for this behavior.Differential Revision: https://reviews.llvm.org/D112747