[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return `void` instead of ~~`bool`~~ Justifications: - The code doesn't ultimately apply the `true`/`false` return values. - The methods already pass around a `CommandReturnObject`, typically with a `result` parameter. - Each command return object already contains: - A more precise status - The error code(s) that apply to that status Part 1 refactors the `CommandObject::Execute(...)` method. - See [https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989) rdar://117378957
Follow up to "Suppress persistent result when running po" (D144044). This change delays removal of the persistent result until after `Dump` has been called. In doing so, the persistent result is available for the purpose of getting its object description. In the original change, the persistent result removal happens indirectly, by setting `EvaluateExpressionOptions::SetSuppressPersistentResult`. In practice this has worked, however this exposed a latent bug in swift-lldb. The subtlety, and the bug, depend on when the persisteted result variable is removed. When the result is removed via `SetSuppressPersistentResult`, it happens within the call to `Target::EvaluateExpression`. That is, by the time the call returns, the persistent result is already removed. The issue occurs shortly thereafter, when `ValueObject::Dump` is called, it cannot make use of the persistent result variable (instead it uses the `ValueObjectConstResult`). In swift-lldb, this causes an additional expression evaluation to happen. It first tries an expression that reference `$R0` etc, but that always fails because `$R0` is removed. The fallback to this failure does work most of the time, but there's at least one bug involving imported Clang types. Differential Revision: https://reviews.llvm.org/D150619
Change `dwim-print` to now disable persistent results by default, unless requested by the user with the `--persistent-result` flag. Ex: ``` (lldb) dwim-print 1 + 1 (int) 2 (lldb) dwim-print --persistent-result on -- 1 + 1 (int) $0 = 2 ``` Users who wish to enable persistent results can make and use an alias that includes `--persistent-result on`. Updates: To recommit this, both TestPersistentResult.py and TestPAlias.py needed to be updated, as well as the changes in D146230. Differential Revision: https://reviews.llvm.org/D145609
This reverts commit 8bad4ae679df6fc7dbd016dccbd3da34206e836b.
Change `dwim-print` to now disable persistent results by default, unless requested by the user with the `--persistent-result` flag. Ex: ``` (lldb) dwim-print 1 + 1 (int) 2 (lldb) dwim-print --persistent-result on -- 1 + 1 (int) $0 = 2 ``` Users who wish to enable persistent results can make and use an alias that includes `--persistent-result on`. Differential Revision: https://reviews.llvm.org/D145609
Context: The `expression` command uses artificial variables to store the expression result. This result variable is unconditionally kept around after the expression command has completed. These variables are known as persistent results. These are the variables `$0`, `$1`, etc, that are displayed when running `p` or `expression`. This change allows users to control whether result variables are persisted, by introducing a `--persistent-result` flag. This change keeps the current default behavior, persistent results are created by default. This change gives users the ability to opt-out by re-aliasing `p`. For example: ``` command unalias p command alias p expression --persistent-result false -- ``` For consistency, this flag is also adopted by `dwim-print`. Of note, if asked, `dwim-print` will create a persistent result even for frame variables. Differential Revision: https://reviews.llvm.org/D144230
Adopt `expression`'s options in `dwim-print`. This is primarily added to support the `--language`/`-l` flag. Differential Revision: https://reviews.llvm.org/D144114
Summary: LLDB keeps statistics of how many expression evaluations are 'successful' and 'failed' which are updated after each expression evaluation (assuming statistics are enabled). From what I understand the idea is that this could be used to define how well LLDB's expression evaluator is working. Currently all expressions are considered successful unless the user passes an explicit positive element counting to the expression command (with the `-Z` flag) and then passes an expression that successfully evaluates to a type that doesn't support element counting. Expressions that fail to parse, execute or any other outcome are considered successful at the moment which means we nearly always have a 100% expression evaluation success rate. This patch makes that expressions that fail to parse or execute to count as failed expressions. We can't know whether the expression failed because of an user error of because LLDB couldn't correctly parse/compile it, but I would argue that this is still an improvement. Assuming that the percentage of valid user expressions stays mostly constant over time (which seems like a reasonable assumption), then this way we can still see if we are doing relatively better/worse from release to release. Reviewers: davide, aprantl, JDevlieghere Reviewed By: aprantl Subscribers: abidh Differential Revision: https://reviews.llvm.org/D76280
The error_stream and result parameter were inconsistently checked for being null, so we might as well make them references instead of crashing in case someone passes a nullptr and hits one of the code paths that are currently not doing a nullptr check on those parameters. Also change output_stream for consistency.