[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, test] Fix typos in the lldb testsReviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D126596
[lldb] Fix that the expression commands --top-level flag overwrites --allow-jit falseThe `--allow-jit` flag allows the user to force the IR interpreter to run theprovided expression.The `--top-l
[lldb] Fix that the expression commands --top-level flag overwrites --allow-jit falseThe `--allow-jit` flag allows the user to force the IR interpreter to run theprovided expression.The `--top-level` flag parses and injects the code as if its in the top levelscope of a source file.Both flags just change the ExecutionPolicy of the expression:* `--allow-jit true` -> doesn't change anything (its the default)* `--allow-jit false` -> ExecutionPolicyNever* `--top-level` -> ExecutionPolicyTopLevelPassing `--allow-jit false` and `--top-level` currently causes the `--top-level`to silently overwrite the ExecutionPolicy value that was set by `--allow-jitfalse`. There isn't any ExecutionPolicy value that says "top-level but onlyinterpret", so I would say we reject this combination of flags until someonefinds time to refactor top-level feature out of the ExecutionPolicy enum.The SBExpressionOptions suffer from a similar symptom as `SetTopLevel` and`SetAllowJIT` just silently disable each other. But those functions don't haveany error handling, so not a lot we can do about this in the meantime.Reviewed By: labath, kastiglioneDifferential Revision: https://reviews.llvm.org/D91780
[lldb] Use assertIn/NotIn over assertTrue/False (NFC)For improved failure messages, use `assertIn` over `assertTrue`.Differential Revision: https://reviews.llvm.org/D96095
[lldb/Test] Introduce "assertSuccess"Summary:A lot of our tests do 'self.assertTrue(error.Success()'. The problemwith that is that when this fails, it produces a completely uselesserror message
[lldb/Test] Introduce "assertSuccess"Summary:A lot of our tests do 'self.assertTrue(error.Success()'. The problemwith that is that when this fails, it produces a completely uselesserror message (False is not True) and the most important piece ofinformation -- the actual error message -- is completely hidden.Sometimes we mitigate that by including the error message in the "msg"argument, but this has two additional problems:- as the msg argument is evaluated unconditionally, one needs to be careful to not trigger an exception when the operation was actually successful.- it requires more typing, which means we often don't do itassertSuccess solves these problems by taking the entire SBError objectas an argument. If the operation was unsuccessful, it can format areasonable error message itself. The function still accepts a "msg"argument, which can include any additional context, but this context nowdoes not need to include the error message.To demonstrate usage, I replace a number of existing assertTrueassertions with the new function. As this process is not easilyautomatable, I have just manually updated a representative sample. Insome cases, I did not update the code to use assertSuccess, but I wentfor even higher-level assertion apis (runCmd, expect_expr), as these areeven shorter, and can produce even better failure messages.Reviewers: teemperor, JDevlieghereSubscribers: arphaman, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D82759
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdi
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151