[lldb] Expose structured errors in SBError (#120784)

Building on top of previous work that exposed expression diagnostics via
SBCommandReturnObject, this patch generalizes the support to expose any

[lldb] Expose structured errors in SBError (#120784)

Building on top of previous work that exposed expression diagnostics via
SBCommandReturnObject, this patch generalizes the support to expose any
SBError as machine-readable structured data. One use-case of this is to
allow IDEs to better visualize expression diagnostics.

rdar://139997604

show more ...

[lldb] Highlight "note:" in CommandReturnObject (#114610)

We have helpers to emit warnings and errors. Do the same thing for notes
to they stand out more.

[lldb] Expose structured command diagnostics via the SBAPI. (#112109)

This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB.

[lldb] Expose structured command diagnostics via the SBAPI. (#112109)

This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB. It is exposed
as a versioned SBStructuredData object, since it is expected that this
may need to be tweaked based on actual usage.

show more ...

[lldb] Rename CommandReturnObject::Get.*Data -> Get.*String (#112062)

In a later commit, I want to add a method to access diagnostics as
actual structured data, which will make these function names

[lldb] Rename CommandReturnObject::Get.*Data -> Get.*String (#112062)

In a later commit, I want to add a method to access diagnostics as
actual structured data, which will make these function names rather
confusing.

show more ...

Support inline diagnostics in CommandReturnObject (#110901)

and implement them for dwim-print (a.k.a. `p`) as an example.

The next step will be to expose them as structured data in
SBCommandRetu

Support inline diagnostics in CommandReturnObject (#110901)

and implement them for dwim-print (a.k.a. `p`) as an example.

The next step will be to expose them as structured data in
SBCommandReturnObject.

show more ...

[lldb] Unify implementation of CommandReturnObject::SetError(NFC) (#110707)

This is a cleanup that moves the API towards value semantics.

Streamline expression parser error messages.

Currently the expression parser prints a mostly useless generic error before printing the compiler error:

(lldb) p 1+x)
error: expression failed to

Streamline expression parser error messages.

Currently the expression parser prints a mostly useless generic error before printing the compiler error:

(lldb) p 1+x)
error: expression failed to parse:
error: <user expression 18>:1:3: use of undeclared identifier 'x'
1+x)
^

This is distracting and as far as I can tell only exists to work
around the fact that the first "error: " is unconditionally injected
by CommandReturnObject. The solution is not very elegant, but the
result looks much better.

(Partially addresses rdar://110492710)

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

show more ...

[lldb] Show the DBGError if dsymForUUID can't find a dSYM

Show the user the DBGError (if available) when dsymForUUID fails.

rdar://90949180

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

[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 ...

[NFC] const-ify some methods on CommandReturnObject

[lldb] Remove asserts in CommandReturnObject SetError and AppendError

I added asserts to these in https://reviews.llvm.org/D104525.
They are available (directly or otherwise) via the API so we
shoul

[lldb] Remove asserts in CommandReturnObject SetError and AppendError

I added asserts to these in https://reviews.llvm.org/D104525.
They are available (directly or otherwise) via the API so we
should not assert.

Restore the previous behaviour. If the message
is empty, we return early before printing anything.
For SetError don't assert that the error is a failure.

The remaining assert is in AppendRawError which
is not part of the API.

Reviewed By: teemperor

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

show more ...

[lldb] Remove CommandReturnObject's SetError(StringRef)

Replacing existing uses with AppendError.

SetError is also part of the SBI API. This remains
but instead of calling the underlying SetError i

[lldb] Remove CommandReturnObject's SetError(StringRef)

Replacing existing uses with AppendError.

SetError is also part of the SBI API. This remains
but instead of calling the underlying SetError it
will call AppendError.

Reviewed By: teemperor

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

show more ...

[lldb] Assert that CommandResultObject error messages are not empty

The intention is now that AppendError/SetError/AppendRawError only
be called with some message to show. This enforces that.

For S

[lldb] Assert that CommandResultObject error messages are not empty

The intention is now that AppendError/SetError/AppendRawError only
be called with some message to show. This enforces that.

For SetError with a Status and a fallback string first assert
that the Status is a failure Status. Then it calls SetError(StringRef)
which checks the message is valid. (which could be the fallback
or the Status')

Reviewed By: dblaikie

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

show more ...

[lldb] Set return object failed status even if error string is empty

The idea is now that AppendError<...> will set eReturnStatusFailed
for you so you don't have to call SetStatus again.

Previously

[lldb] Set return object failed status even if error string is empty

The idea is now that AppendError<...> will set eReturnStatusFailed
for you so you don't have to call SetStatus again.

Previously if the error message was empty, the status wouldn't
be set.

I don't think there are any sitautions where the message is in
fact empty but it potentially could be depending on where
we get the string from.

So let's set the status up front then return early if the message is empty.

Reviewed By: teemperor

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

show more ...

Reland "[lldb] Set return status to failed when adding a command error"

This reverts commit ac031c8db2ce454a9b08f23192ce698e8bde4447.

SB API usage has been corrected.

Revert "[lldb] Set return status to failed when adding a command error" (and fixups)

This reverts commit f583029da3d6dbabe82f48b160227eb0120abd33,
0f94d68a2e15d50796439f20bcb508b95931d2ae and
a2363c

Revert "[lldb] Set return status to failed when adding a command error" (and fixups)

This reverts commit f583029da3d6dbabe82f48b160227eb0120abd33,
0f94d68a2e15d50796439f20bcb508b95931d2ae and
a2363c0cf9b6a9a81c76ac652da667f73845d38b.

Due to test failures from incorrect SB API usage.

show more ...

Reland "[lldb] Set return status to failed when adding a command error"

This reverts commit db93e4e70aa453e5ba04ba0d9e01f581882b6c81.

This modifies TestRegsters.py to account for Darwin showing
AVX

Reland "[lldb] Set return status to failed when adding a command error"

This reverts commit db93e4e70aa453e5ba04ba0d9e01f581882b6c81.

This modifies TestRegsters.py to account for Darwin showing
AVX registers as part of "Floating Point Registers" instead
of in a separate "Advanced Vector Extensions" category.

show more ...

Revert "[lldb] Set return status to failed when adding a command error"

This reverts commit e05b03cf4f45ac5ee63c59a3464e7d484884645c.

While I investigate a register test failure:
http://green.lab.l

Revert "[lldb] Set return status to failed when adding a command error"

This reverts commit e05b03cf4f45ac5ee63c59a3464e7d484884645c.

While I investigate a register test failure:
http://green.lab.llvm.org/green/blue/organizations/jenkins/lldb-cmake/detail/lldb-cmake/32693/pipeline/

show more ...

[lldb] Don't print script output twice in HandleCommand

When executing a script command in HandleCommand(s) we currently print
its output twice
You can see this issue in action when adding a breakpo

[lldb] Don't print script output twice in HandleCommand

When executing a script command in HandleCommand(s) we currently print
its output twice
You can see this issue in action when adding a breakpoint command:

(lldb) b main
Breakpoint 1: where = main.out`main + 13 at main.cpp:2:3, address = 0x0000000100003fad
(lldb) break command add 1 -o "script print(\"Hey!\")"
(lldb) r
Process 76041 launched: '/tmp/main.out' (x86_64)
Hey!
(lldb) script print("Hey!")
Hey!
Process 76041 stopped

The issue is caused by HandleCommands using a temporary
CommandReturnObject and one of the commands (`script` in this case)
setting an immediate output stream. This causes the result to be printed
twice: once directly to the immediate output stream and once when
printing the result of HandleCommands.

This patch fixes the issue by introducing a new option to suppress
immediate output for temporary CommandReturnObjects.

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

show more ...

[lldb] Set return status to failed when adding a command error

There is a common pattern:
result.AppendError(...);
result.SetStatus(eReturnStatusFailed);

I found that some commands don't actually "

[lldb] Set return status to failed when adding a command error

There is a common pattern:
result.AppendError(...);
result.SetStatus(eReturnStatusFailed);

I found that some commands don't actually "fail" but only
print "error: ..." because the second line got missed.

This can cause you to miss a failed command when you're
using the Python interface during testing.
(and produce some confusing script results)

I did not find any place where you would want to add
an error without setting the return status, so just
set eReturnStatusFailed whenever you add an error to
a command result.

This change does not remove any of the now redundant
SetStatus. This should allow us to see if there are any
tests that have commands unexpectedly fail with this change.
(the test suite passes for me but I don't have access to all
the systems we cover so there could be some corner cases)

Some tests that failed on x86 and AArch64 have been modified
to work with the new behaviour.

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

show more ...

[lldb/Interpreter][NFC] Replace default constructors/destructors bodies with "=default"

[lldb] Prevent double new lines behind errors/warning/messages from LLDB commands

The current API for printing errors/warnings/messages from LLDB commands
sometimes adds newlines behind the messages

[lldb] Prevent double new lines behind errors/warning/messages from LLDB commands

The current API for printing errors/warnings/messages from LLDB commands
sometimes adds newlines behind the messages for the caller. However, this
happens unconditionally so when the caller already specified a trailing newline
in the error message (or is trying to print a generated error message that ends
in a newline), LLDB ends up printing both the automatically added newline and
the one that was in the error message string. This leads to all the randomly
appearing new lines in error such as:

```
(lldb) command a
error: 'command alias' requires at least two arguments
(lldb) apropos a b
error: 'apropos' must be called with exactly one argument.

(lldb) why is there an empty line behind the second error?
```

This code adds a check that only appends the new line if the passed message
doesn't already contain a trailing new line.

Also removes the AppendRawWarning which had only one caller and doesn't serve
any purpose now.

Reviewed By: #lldb, mib

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

show more ...

[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/Interpreter] Remove redundant argument (NFC)

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 ...