[lldb] Remove redundant .c_str() and .get() calls

Removing .c_str() has a semantics difference, but the use scenarios
likely do not matter as we don't have NUL in the strings.

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it.

When UserExpression::Evaluate() fails and doesn't return a ValueObject there is no vehicle for returning th

Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it.

When UserExpression::Evaluate() fails and doesn't return a ValueObject there is no vehicle for returning the error in the return value.

This behavior can be observed by applying the following patch:

diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1a311b7252c..58c03ccdb068 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -2370,6 +2370,7 @@ UserExpression *Target::GetUserExpressionForLanguage(
Expression::ResultType desired_type,
const EvaluateExpressionOptions &options, ValueObject *ctx_obj,
Status &error) {
+ error.SetErrorStringWithFormat("Ha ha!"); return nullptr;
auto type_system_or_err = GetScratchTypeSystemForLanguage(language);
if (auto err = type_system_or_err.takeError()) {
error.SetErrorStringWithFormat(

and then running

$ lldb -o "p 1"
(lldb) p 1
(lldb)

This patch fixes this by creating an empty result ValueObject that wraps the error.

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

show more ...

Revert "Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it."

This reverts commit a31a5da3c7d7393749a43dbc678fd28fb94d07f6.

Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it.

When UserExpression::Evaluate() fails and doesn't return a ValueObject there is no vehicle for returning th

Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it.

When UserExpression::Evaluate() fails and doesn't return a ValueObject there is no vehicle for returning the error in the return value.

This behavior can be observed by applying the following patch:

diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f1a311b7252c..58c03ccdb068 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -2370,6 +2370,7 @@ UserExpression *Target::GetUserExpressionForLanguage(
Expression::ResultType desired_type,
const EvaluateExpressionOptions &options, ValueObject *ctx_obj,
Status &error) {
+ error.SetErrorStringWithFormat("Ha ha!"); return nullptr;
auto type_system_or_err = GetScratchTypeSystemForLanguage(language);
if (auto err = type_system_or_err.takeError()) {
error.SetErrorStringWithFormat(

and then running

$ lldb -o "p 1"
(lldb) p 1
(lldb)

This patch fixes this by creating an empty result ValueObject that wraps the error.

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

show more ...

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outli

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

show more ...

[lldb] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options t

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options that use the same argument type have
the same accepted values.
- We can print the enum values and their description in the help
output. (D129707)

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

show more ...

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Dif

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

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

show more ...

[lldb] Remove commented-out code in CommandObjectExpression (NFC)

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

Modify "statistics dump" to dump JSON.

This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get st

Modify "statistics dump" to dump JSON.

This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get stats from the current target. It adds 3 new stats as well. The output of "statistics dump" is now emitted as JSON so that it can be used to track performance and statistics and the output could be used to populate a database that tracks performance. Sample output looks like:

(lldb) statistics dump
{
"expressionEvaluation": {
"failures": 0,
"successes": 0
},
"firstStopTime": 0.34164492800000001,
"frameVariable": {
"failures": 0,
"successes": 0
},
"launchOrAttachTime": 0.31969605400000001,
"targetCreateTime": 0.0040863039999999998
}

The top level keys are:

"expressionEvaluation" which replaces the previous stats that were emitted as plain text. This dictionary contains the success and fail counts.
"frameVariable" which replaces the previous stats for "frame variable" that were emitted as plain text. This dictionary contains the success and fail counts.
"targetCreateTime" contains the number of seconds it took to create the target and load dependent libraries (if they were enabled) and also will contain symbol preloading times if that setting is enabled.
"launchOrAttachTime" is the time it takes from when the launch/attach is initiated to when the first private stop occurs.
"firstStopTime" is the time in seconds that it takes to stop at the first stop that is presented to the user via the LLDB interface. This value will only have meaning if you set a known breakpoint or stop location in your code that you want to measure as a performance test.

This diff is also meant as a place to discuess what we want out of the "statistics dump" command before adding more funcionality. It is also meant to clean up the previous code that was storting statistics in a vector of numbers within the lldb_private::Target class.

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

show more ...

[lldb] Show fix-it applied even if expression didn't evaluate succesfully

If we applied a fix-it before evaluating an expression and that
expression didn't evaluate correctly, we should still tell u

[lldb] Show fix-it applied even if expression didn't evaluate succesfully

If we applied a fix-it before evaluating an expression and that
expression didn't evaluate correctly, we should still tell users about
the fix-it we applied since that may be the reason why it didn't work
correctly.

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

show more ...

[lldb] Remove redundant calls to set eReturnStatusFailed

This is part 2, covering the commands source.

Some uses remain where it's tricky to see what the
logic is or they are not used with AppendEr

[lldb] Remove redundant calls to set eReturnStatusFailed

This is part 2, covering the commands source.

Some uses remain where it's tricky to see what the
logic is or they are not used with AppendError.

Reviewed By: teemperor

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

show more ...

[lldb] Fix that the expression commands --top-level flag overwrites --allow-jit false

The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.

The `--top-l

[lldb] Fix that the expression commands --top-level flag overwrites --allow-jit false

The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.

The `--top-level` flag parses and injects the code as if its in the top level
scope 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` -> ExecutionPolicyTopLevel

Passing `--allow-jit false` and `--top-level` currently causes the `--top-level`
to silently overwrite the ExecutionPolicy value that was set by `--allow-jit
false`. There isn't any ExecutionPolicy value that says "top-level but only
interpret", so I would say we reject this combination of flags until someone
finds 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 have
any error handling, so not a lot we can do about this in the meantime.

Reviewed By: labath, kastiglione

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

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] Make GetSelectedOrDummyTarget return the target by reference (NFC)

Return references from GetDummyTarget and GetSelectedOrDummyTarget. This
matches how the APIs are already used in practice.

[lldb/Interpreter] Support color in CommandReturnObject

Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabl

[lldb/Interpreter] Support color in CommandReturnObject

Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.

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

show more ...

[lldb] Add option to retry Fix-Its multiple times to failed expressions

Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently

[lldb] Add option to retry Fix-Its multiple times to failed expressions

Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.

This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).

The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.

Reviewers: jingham, JDevlieghere, friss, shafik

Reviewed By: shafik

Subscribers: shafik, abidh

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

show more ...

[lldb] Mark expressions that couldn't be parsed or executed as failed expressions

Summary:
LLDB keeps statistics of how many expression evaluations are 'successful' and 'failed'
which are updated af

[lldb] Mark expressions that couldn't be parsed or executed as failed expressions

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

show more ...

[lldb] Ptrs->refs in CommandObjectExpression::EvaluateExpression parameters

The error_stream and result parameter were inconsistently checked for
being null, so we might as well make them references

[lldb] Ptrs->refs in CommandObjectExpression::EvaluateExpression parameters

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.

show more ...

[lldb][NFC] Refactor our option generation out of EvaluateExpression

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...