[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
The `po` alias now matches the behavior of the `expression` command when
the it can apply a Fix-It to an expression.
Modifications
- Add has `m_fixed_expression` to the `CommandObjectDWIMPrint` class a
`protected` member that stores the post Fix-It expression, just like the
`CommandObjectExpression` class.
- Converted messages to present tense.
- Add test cases that confirms a Fix-It for a C++ expression for both
`po` and `expressions`
rdar://115317419
The `po` alias now matches the behavior of the `expression` command when
the it can apply a Fix-It to an expression.
Modifications
- Add has `m_fixed_expression` to the `CommandObjectDWIMPrint` class a
`protected` member that stores the post Fix-It expression, just like the
`CommandObjectExpression` class.
- Converted messages to present tense.
- Add test cases that confirms a Fix-It for a C++ expression for both
`po` and `expressions`
rdar://115317419
Co-authored-by: Pete Lawrence <plawrence@apple.com>
Lots of users use "po" as their default print command. If the type
doesn't implement the description function the output is often not what
the user wants. Print a hint telling the user that they might prefer
using "p" instead.
Differential Revision: https://reviews.llvm.org/D153489
This patch should allow the user to set specific auto-completion type
for their custom commands.
To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.
So now, the user can specify which completion type will be used with
their custom command, when they register it.
This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.
Differential Revision: https://reviews.llvm.org/D152011
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Expression evaluation for `void` valued expressions sets an error using the `kNoResult`
code. Like the `expression` command, `dwim-print` should also not print such errors.
Before:
```
(lldb) dwim-print (void)printf("hi\n")
hi
Error: 'unknown error'
```
After:
```
(lldb) dwim-print (void)printf("hi\n")
hi
```
rdar://109746544
Differential Revision: https://reviews.llvm.org/D151351
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
When printing a value, allow the root value's name to be elided, without omiting the
names of child values.
At the API level, this adds `SetHideRootName()`, which joins the existing
`SetHideName()` function.
This functionality is used by `dwim-print` and `expression`.
Fixes an issue identified by @jgorbe in https://reviews.llvm.org/D145609.
Differential Revision: https://reviews.llvm.org/D146783
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
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
Add support for the `--gdb-format`/`-G` flag to `dwim-print`.
The gdb-format flag allows users to alias `p` to `dwim-print`.
Differential Revision: https://reviews.llvm.org/D141425
Allow `dwim-print` to evaluate expressions using the dummy target if no real
target exists.
This adds some parity to `expression`. With this, both of the following work:
```
lldb -o 'expr 1+2'
lldb -o 'dwim-print 1+2'
```
Differential Revision: https://reviews.llvm.org/D138960
Implements `dwim-print`, a printing command that chooses the most direct,
efficient, and resilient means of printing a given expression.
DWIM is an acronym for Do What I Mean. From Wikipedia, DWIM is described as:
> attempt to anticipate what users intend to do, correcting trivial errors
> automatically rather than blindly executing users' explicit but
> potentially incorrect input
The `dwim-print` command serves as a single print command for users who don't
yet know, or prefer not to know, the various lldb commands that can be used to
print, and when to use them.
This initial implementation is the base foundation for `dwim-print`. It accepts
no flags, only an expression. If the expression is the name of a variable in
the frame, then effectively `frame variable` is used to get, and print, its
value. Otherwise, printing falls back to using `expression` evaluation. In this
initial version, frame variable paths will be handled with `expression`.
Following this, there are a number of improvements that can be made. Some
improvements include supporting `frame variable` expressions or registers.
To provide transparency, especially as the `dwim-print` command evolves, a new
setting is also introduced: `dwim-print-verbosity`. This setting instructs
`dwim-print` to optionally print a message showing the effective command being
run. For example `dwim-print var.meth()` can print a message such as: "note:
ran `expression var.meth()`".
See https://discourse.llvm.org/t/dwim-print-command/66078 for the proposal and
discussion.
Differential Revision: https://reviews.llvm.org/D138315
