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

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

[lldb] Add assertStopReason helper function

Add a function to make it easier to debug a test failure caused by an
unexpected stop reason. This is similar to the assertState helper that
was added in

[lldb] Add assertStopReason helper function

Add a function to make it easier to debug a test failure caused by an
unexpected stop reason. This is similar to the assertState helper that
was added in ce825e46743b.

Before:

self.assertEqual(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: 5 != 10

After:

self.assertStopReason(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: signal (5) != instrumentation (10)

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

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] Add assertState function to the API test suite

Add a function to make it easier to debug a test failure caused by an
unexpected state.

Currently, tests are using assertEqual which results in

[lldb] Add assertState function to the API test suite

Add a function to make it easier to debug a test failure caused by an
unexpected state.

Currently, tests are using assertEqual which results in a cryptic error
message: "AssertionError: 5 != 10". Even when a test provides a message
to make it clear why a particular state is expected, you still have to
figure out which of the two was the expected state, and what the other
value corresponds to.

We have a function in lldbutil that helps you convert the state number
into a user readable string. This patch adds a wrapper around
assertEqual specifically for comparing states and reporting better error
messages.

The aforementioned error message now looks like this: "AssertionError:
stopped (5) != exited (10)". If the user provided a message, that
continues to get printed as well.

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

show more ...

[LLDB] Remove decorator from XPASSes AArch64/Windows

This patch remove XFAIL decorator from tests which as passing on AArch64
Windows. This is tested on surface pro x using tot llvm and clang 14.0.3

[LLDB] Remove decorator from XPASSes AArch64/Windows

This patch remove XFAIL decorator from tests which as passing on AArch64
Windows. This is tested on surface pro x using tot llvm and clang 14.0.3
as compiler with visual studio 2019 x86_arm64 environment.

show more ...

We don't require users to type out the full context of a function, for
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then co

We don't require users to type out the full context of a function, for
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then compare
the rest of the context that the user provided to make sure it
matches. However, we do this comparison using just a strstr. So for
instance:

break set -n foo::bar

will match not only "a::foo::bar" but "notherfoo::bar". The former is
pretty clearly the user's intent, but I don't think the latter is, and
results in breakpoints picking up too many matches.

This change adds a Language::DemangledNameContainsPath API which can
do a language aware match against the path provided. If the language
doesn't provide this we fall back to the strstr (though that's changed
to StringRef::contains in the patch).

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

show more ...

Don't report memory return values on MacOS_arm64 of SysV_arm64 ABI's.

They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is corre

Don't report memory return values on MacOS_arm64 of SysV_arm64 ABI's.

They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is correct. It's better
to return nothing that something that's not accurate.

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

show more ...

[lldb] Replace asserts on .Success() with assertSuccess()

Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).

* `assertSuccess` prints out the error's message

[lldb] Replace asserts on .Success() with assertSuccess()

Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).

* `assertSuccess` prints out the error's message
* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output
* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge
* `assertSuccess` statements are more succinct

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

show more ...

[lldb] Include arm64 in affected_by_radar_34562999

The same issue impacts arm64, both on-device and on Apple Silicon.

[LLDB] Testsuite: Add helper to check for AArch64 target

This patch adds a helper function to test target architecture is
AArch64 or not. This also tightens isAArch64* helpers by adding an
extra arc

[LLDB] Testsuite: Add helper to check for AArch64 target

This patch adds a helper function to test target architecture is
AArch64 or not. This also tightens isAArch64* helpers by adding an
extra architecture check.

Reviewed By: DavidSpickett

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

show more ...

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

[lldb] Convert assertTrue(a == b) to assertEqual(a, b)

Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.

These were mostly done via regex search & replace, wit

[lldb] Convert assertTrue(a == b) to assertEqual(a, b)

Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.

These were mostly done via regex search & replace, with some manual fixes.

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

show more ...

[lldb] [test] Link FreeBSD test failures to bugs

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

[TestReturnValue] Skip based on architecutre, not platform.

[LLDB] Decorate tests failing on arm-linux buildbot

Tests impacted by these decorators fail on arm-linux-gnueabihf.

These have been triaged and appropriate bugs have been filed.

[lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suite

Summary:
The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely usel

[lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suite

Summary:
The error message from the construct `assertTrue(a == b, "msg") ` are nearly always completely useless for actually debugging the issue.
This patch is just replacing this construct (and similar ones like `assertTrue(a != b, ...)` with the proper call to assertEqual or assertNotEquals.

This patch was mostly written by a shell script with some manual verification afterwards:
```
lang=python
import sys

def sanitize_line(line):
if line.strip().startswith("self.assertTrue(") and " == " in line:
line = line.replace("self.assertTrue(", "self.assertEquals(")
line = line.replace(" == ", ", ", 1)
if line.strip().startswith("self.assertTrue(") and " != " in line:
line = line.replace("self.assertTrue(", "self.assertNotEqual(")
line = line.replace(" != ", ", ", 1)
return line

for a in sys.argv[1:]:
with open(a, "r") as f:
lines = f.readlines()
with open(a, "w") as f:
for line in lines:
f.write(sanitize_line(line))
```

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh, lldb-commits

Tags: #lldb

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

show more ...

[lldb][test] Remove symlink for API tests.

Summary: Moves lldbsuite tests to lldb/test/API.

This is a largely mechanical change, moved with the following steps:

```
rm lldb/test/API/testcases
mkdi

[lldb][test] Remove symlink for API tests.

Summary: Moves lldbsuite tests to lldb/test/API.

This is a largely mechanical change, moved with the following steps:

```
rm lldb/test/API/testcases
mkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}
mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runner
for d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done
```

lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.

Reviewers: labath, JDevlieghere

Tags: #lldb

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

show more ...