CommandObjectRegexCommand shouldn't put two commands on the history stack.

It was putting the command the user typed, and then the resolved command in the
command history. That caused up-arrow not

CommandObjectRegexCommand shouldn't put two commands on the history stack.

It was putting the command the user typed, and then the resolved command in the
command history. That caused up-arrow not to work correctly when the regex command
was invoked from a Python-command. Plus it's just weird.

Differential Revision: https://reviews.llvm.org/D126789

show more ...

[lldb] Fix (unintentional) recursion in CommandObjectRegexCommand

Jim noticed that the regex command is unintentionally recursive. Let's
use the following command regex as an example:

(lldb) com

[lldb] Fix (unintentional) recursion in CommandObjectRegexCommand

Jim noticed that the regex command is unintentionally recursive. Let's
use the following command regex as an example:

(lldb) com regex humm 's/([^ ]+) ([^ ]+)/p %1 %2 %1 %2/'

If we call it with arguments foo bar, thing behave as expected:

(lldb) humm foo bar
(...)
foo bar foo bar

However, if we include %2 in the arguments, things break down:

(lldb) humm fo%2o bar
(...)
fobaro bar fobaro bar

The problem is that the implementation of the substitution is too naive.
It substitutes the %1 token into the target template in place, then does
the %2 substitution starting with the resultant string. So if the
previous substitution introduced a %2 token, it would get processed in
the second sweep, etc.

This patch addresses the issue by walking the command once and
substituting the % variables in place.

(lldb) humm fo%2o bar
(...)
fo%2o bar fo%2o bar

Furthermore, this patch also reports an error if not enough variables
were provided and add support for substituting %0.

rdar://81236994

Differential revision: https://reviews.llvm.org/D120101

show more ...

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

Fix a thinko in the parsing of substitutions in CommandObjectRegexCommand.

The old code incorrectly calculated the start position for the search
for the third (and subsequent) instance of a particul

Fix a thinko in the parsing of substitutions in CommandObjectRegexCommand.

The old code incorrectly calculated the start position for the search
for the third (and subsequent) instance of a particular substitution
pattern (e.g. %1).

I also added a few test cases for this parsing covering this failure.

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041

show more ...

Reland "[lldb] Make CommandInterpreter's execution context the same as debugger's one"

Revert "[lldb] Make CommandInterpreter's execution context the same as debugger's one."

This reverts commit a01b26fb51c710a3a8ef88cc83b0701461f5b9ab, because it
breaks the "finish" command in some w

Revert "[lldb] Make CommandInterpreter's execution context the same as debugger's one."

This reverts commit a01b26fb51c710a3a8ef88cc83b0701461f5b9ab, because it
breaks the "finish" command in some way -- the command does not
terminate after it steps out, but continues running the target. The
exact blast radius is not clear, but it at least affects the usage of
the "finish" command in TestGuiBasicDebug.py. The error is *not*
gui-related, as the same issue can be reproduced by running the same
steps outside of the gui.

There is some kind of a race going on, as the test fails only 20% of the
time on the buildbot.

show more ...

[lldb] Make CommandInterpreter's execution context the same as debugger's one.

Currently, the interpreter's context is not updated until a command is executed.
This has resulted in the behavior of S

[lldb] Make CommandInterpreter's execution context the same as debugger's one.

Currently, the interpreter's context is not updated until a command is executed.
This has resulted in the behavior of SB-interface functions and some commands
depends on previous user actions. The interpreter's context can stay uninitialized,
point to a currently selected target, or point to one of previously selected targets.

This patch removes any usages of CommandInterpreter::UpdateExecutionContext.
CommandInterpreter::HandleCommand* functions still may override context temporarily,
but now they always restore it before exiting. CommandInterpreter saves overriden
contexts to the stack, that makes nesting commands possible.

Added test reproduces one of the issues. Without this fix, the last assertion fails
because interpreter's execution context is empty until running "target list", so,
the value of the global property was updated instead of process's local instance.

Differential Revision: https://reviews.llvm.org/D92164

show more ...

[lldb] Move ScriptCommand and RegexCommand under Commands (NFC)

Move the CommandObjectScript and CommandObjectRegexCommand under
Commands where all the other CommandObject implementations live.

Alt

[lldb] Move ScriptCommand and RegexCommand under Commands (NFC)

Move the CommandObjectScript and CommandObjectRegexCommand under
Commands where all the other CommandObject implementations live.

Although neither implementations currently use the TableGen-generated
CommandOptions.inc, this move would have been necessary anyway if they
were to in the future.

show more ...