[lldb] Refactor UserExpression::Evaluate to only have one error channel. (#117186)

Prior to this patch, the function returned an exit status, sometimes a
ValueObject with an error and a Status obje

[lldb] Refactor UserExpression::Evaluate to only have one error channel. (#117186)

Prior to this patch, the function returned an exit status, sometimes a
ValueObject with an error and a Status object. This patch removes the
Status object and ensures the error is consistently returned as the
error of the ValueObject.

show more ...

[lldb][Test] Remove some xfails for AArch64 Linux

PR #92245 fixed these tests on Linux. They likely work on FreeBSD too
but leaving the xfail for that so it can be confirmed later.

Also updated a b

[lldb][Test] Remove some xfails for AArch64 Linux

PR #92245 fixed these tests on Linux. They likely work on FreeBSD too
but leaving the xfail for that so it can be confirmed later.

Also updated a bugzilla link to one that redirects to Github issues.

Relates to issues #43398 and #48751.

show more ...

[lldb][test] Modernize asserts (#82503)

This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsne

[lldb][test] Modernize asserts (#82503)

This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3).

For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`.
This produces better error messages, e.g. `error: unexpectedly found 1
and 2 to be different` instead of `error: False`.

show more ...

[lldb] Replace assertEquals with assertEqual (NFC) (#82073)

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a

[lldb] Replace assertEquals with assertEqual (NFC) (#82073)

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

show more ...

[lldb] Fix `po` alias by printing fix-its to the console. (#68755)

The `po` alias now matches the behavior of the `expression` command when
the it can apply a Fix-It to an expression.
Modification

[lldb] Fix `po` alias by printing fix-its to the console. (#68755)

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

show more ...

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

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problem

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

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

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

Reland "[lldb] Use just-built libcxx for tests when available"

This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
re

Reland "[lldb] Use just-built libcxx for tests when available"

This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:

1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.

Condition (2) is new and introduced in this patch in order to support
tests that are either:

* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.

Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.

For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.

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

show more ...

Revert "[lldb] Use just-built libcxx for tests when available"

This reverts commit c38eeecbc7d929c9601f2189214a7a90d3982a47.

[lldb] Use just-built libcxx for tests when available

This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by

[lldb] Use just-built libcxx for tests when available

This commit improves upon cc0b5ebf7fc8, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:

1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.

Condition (2) is new and introduced in this patch in order to support
tests that are either:

* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.

Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.

For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.

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

show more ...

[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://r

[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

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

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

Also display the underlying error message when displaying a fixit

When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This

Also display the underlying error message when displaying a fixit

When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This
patch shows the underlying error message instead of just the fixit to
make it easier to understand what the error in the expression was.

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

show more ...

[lldb] [test] Update XFAILs for FreeBSD/aarch64

[lldb/Test] Introduce "assertSuccess"

Summary:
A lot of our tests do 'self.assertTrue(error.Success()'. The problem
with that is that when this fails, it produces a completely useless
error message

[lldb/Test] Introduce "assertSuccess"

Summary:
A lot of our tests do 'self.assertTrue(error.Success()'. The problem
with that is that when this fails, it produces a completely useless
error message (False is not True) and the most important piece of
information -- the actual error message -- is completely hidden.

Sometimes we mitigate that by including the error message in the "msg"
argument, but this has two additional problems:
- as the msg argument is evaluated unconditionally, one needs to be
careful to not trigger an exception when the operation was actually
successful.
- it requires more typing, which means we often don't do it

assertSuccess solves these problems by taking the entire SBError object
as an argument. If the operation was unsuccessful, it can format a
reasonable error message itself. The function still accepts a "msg"
argument, which can include any additional context, but this context now
does not need to include the error message.

To demonstrate usage, I replace a number of existing assertTrue
assertions with the new function. As this process is not easily
automatable, I have just manually updated a representative sample. In
some cases, I did not update the code to use assertSuccess, but I went
for even higher-level assertion apis (runCmd, expect_expr), as these are
even shorter, and can produce even better failure messages.

Reviewers: teemperor, JDevlieghere

Subscribers: arphaman, lldb-commits

Tags: #lldb

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

show more ...

[lldb] [testsuite] Fix TestFixIts.py on Linux

Since D77214 there is a testsuite regression for TestFixIts.py
on Fedora 31 x86_64.
File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/commands

[lldb] [testsuite] Fix TestFixIts.py on Linux

Since D77214 there is a testsuite regression for TestFixIts.py
on Fedora 31 x86_64.
File "/home/jkratoch/redhat/llvm-monorepo/lldb/test/API/commands/expression/fixits/TestFixIts.py", line 148, in test_with_target
self.assertEquals(value.GetError().GetCString(), "error: No value")
AssertionError: 'error: error: Multiple internal symbols found for \'d\'\nid = {0x00000d2a}, ran [truncated]... != 'error: No value'

That is because Fedora glibc incl. libm.so contains also ELF debug
symbols and there exists a 'd' symbol:
(gdb) p d
$1 = {i = {0, 1076887552}, d = 16}
(gdb) p &d
$2 = (const number *) 0x7ffff78e8bc0 <d>
(gdb) info sym 0x7ffff78e8bc0
d in section .rodata of /lib64/libm.so.6

$ nm /lib64/libm.so.6 |grep ' d$'
00000000000bfbc0 r d
00000000000caa20 r d
00000000000caa20 r d
00000000000caa20 r d

glibc-build$ for i in `find -name "*.o"`;do nm 2>/dev/null $i|grep ' d$' && echo $i;done
0000000000000080 r d
./math/s_atan-fma4.o
0000000000000080 r d
./math/s_atan-avx.o
0000000000000080 r d
./math/s_atan.o

show more ...

[lldb] Make some asserts in TestFixIts more expressive

[lldb] Refactor TestFixIts so that most of it can run on aarch64-linux

The final function call to `test_X` is failing on aarch64-linux with SIGILL.
Function calls to previous expressions seem to jus

[lldb] Refactor TestFixIts so that most of it can run on aarch64-linux

The final function call to `test_X` is failing on aarch64-linux with SIGILL.
Function calls to previous expressions seem to just not work on aarch64-linux
but I don't see another way to test the multiple-run Fix-Its.

This patch refactors the test that the skipIf for aarch64 Linux only covers
the part of the test that was added D77214.

show more ...

Mark TestFixIts.py xfail for LLDB AArch64/Linux

[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] Also apply Fix-Its in "note:" diagnostics that belong to an error diagnostic

Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error".

[lldb] Also apply Fix-Its in "note:" diagnostics that belong to an error diagnostic

Summary:
LLDB currently applies Fix-Its if they are attached to a Clang diagnostic that has the
severity "error". Fix-Its connected to warnings and other severities are supposed to
be ignored as LLDB doesn't seem to trust Clang Fix-Its in these situations.

However, LLDB also ignores all Fix-Its coming from "note:" diagnostics. These diagnostics
are usually emitted alongside other diagnostics (both warnings and errors), either to keep
a single diagnostic message shorter or because the Fix-It is in a different source line. As they
are technically their own (non-error) diagnostics, we currently are ignoring all Fix-Its associated with them.

For example, this is a possible Clang diagnostic with a Fix-It that is currently ignored:
```
error: <user expression 1>:2:10: too many arguments provided to function-like macro invocation
ToStr(0, {,})
^
<user expression 1>:1:9: macro 'ToStr' defined here
#define ToStr(x) #x
^
<user expression 1>:2:1: cannot use initializer list at the beginning of a macro argument
ToStr(0, {,})
^ ~~~~
```

We also don't store "note:" diagnostics at all, as LLDB's abstraction around the whole diagnostic
concept doesn't have such a concept. The text of "note:" diagnostics is instead
appended to the last non-note diagnostic (which is causing that there is no "note:" text in the
diagnostic above, as all the "note:" diagnostics have been appended to the first "error: ..." text).

This patch fixes the ignored Fix-Its in note-diagnostics by appending them to the last non-note
diagnostic, similar to the way we handle the text in these diagnostics.

Reviewers: JDevlieghere, jingham

Reviewed By: JDevlieghere

Subscribers: abidh

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

show more ...

Recommit "[lldb] Make Fix-Its also apply to top-level expressions""

This reverts commit fe5cb1c25fd6c07bbe3c0c698f36b74e6d04946f as it
was not responsible for breaking the bots. Sorry.

Revert "[lldb] Make Fix-Its also apply to top-level expressions"

This reverts commit 83c81c0a469482888482983c302c09c02680ae7c as
it broke the macOS lldb bots.

[lldb] Make Fix-Its also apply to top-level expressions

Summary:
Currently top-level expressions won't automatically get Fix-Its applied. The reason
for that is that we only set the `m_fixed_text` m

[lldb] Make Fix-Its also apply to top-level expressions

Summary:
Currently top-level expressions won't automatically get Fix-Its applied. The reason
for that is that we only set the `m_fixed_text` member if we have a wrapping
source code (I.e. `m_source_code` is not zero and is wrapping some expressions).

This patch just always sets `m_fixed_text` to get this working.

Reviewers: labath, jingham

Reviewed By: labath

Subscribers: JDevlieghere

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

show more ...