Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# a4c18137 28-Jun-2024 Michael Buch <michaelbuch12@gmail.com>

[lldb][test] Remove duplicate testcase names in API test-suite (#97043)

In one of my recent PRs I mistakenly had two test-cases with the same
name, preventing one of them to run. Since it's an easy

[lldb][test] Remove duplicate testcase names in API test-suite (#97043)

In one of my recent PRs I mistakenly had two test-cases with the same
name, preventing one of them to run. Since it's an easy mistake to make
(e.g., copy pasting existing test-cases), I ran following sanity-check
script over `lldb/test/API`, which found couple of tests which were
losing coverage because of this (or in some cases simply had duplicate
tests):
```
import ast
import sys

filename = sys.argv[1]
print(f'Checking {filename}...')
tree = ast.parse(open(filename, 'r').read())

for node in ast.walk(tree):
if not isinstance(node, ast.ClassDef):
continue

func_names = []
for child in ast.iter_child_nodes(node):
if isinstance(child, ast.FunctionDef):
func_names.append(child.name)

seen_func_names = set()
duplicate_func_names = []
for name in func_names:
if name in seen_func_names:
duplicate_func_names.append(name)
else:
seen_func_names.add(name)

if len(duplicate_func_names) != 0:
print(f'Multiple func names found:\n\t{duplicate_func_names}\n\tclass {node.name}\n\tfile: {filename}')
```

This patch fixes these cases.

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5
# 2238dcc3 25-May-2023 Jonas Devlieghere <jonas@devlieghere.com>

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


Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6
# 4cc8f2a0 17-Jun-2022 Dave Lee <davelee.com@gmail.com>

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


# 13dfe0f0 17-Jun-2022 Michał Górny <mgorny@moritz.systems>

[lldb] [test] Update baseline test status for FreeBSD

Fixes #19721
Fixes #18440
Partially fixes bug #47660
Fixes #47761
Fixes #47763

Sponsored by: The FreeBSD Foundation


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# f8d42c55 15-Feb-2022 Pavel Labath <pavel@labath.sk>

[lldb] Fix thread syncrhonization TestThreadBacktraceRepeat

lldb reports (and lldbutil.continue_to_breakpoint returns) a stop reason
even for suspended threads. Fix the test to expect that.

This wa

[lldb] Fix thread syncrhonization TestThreadBacktraceRepeat

lldb reports (and lldbutil.continue_to_breakpoint returns) a stop reason
even for suspended threads. Fix the test to expect that.

This was making the test flaky, as most of the time, the two threads
stop simultaneously, and the synchronization code is not executed.

show more ...


# 0e0e381a 15-Feb-2022 Jim Ingham <jingham@apple.com>

This test seems to pass on Linux, remove the x-fail.

One of the tests in this test setup was copied from a more complex test, and I didn't know
if the setup or the subsequent parts of the test were

This test seems to pass on Linux, remove the x-fail.

One of the tests in this test setup was copied from a more complex test, and I didn't know
if the setup or the subsequent parts of the test were the ones that fail on Linux. Looks
like it was the latter, so let's mark this succeeding.

show more ...


Revision tags: llvmorg-14.0.0-rc1
# 635f03fe 04-Feb-2022 Jim Ingham <jingham@apple.com>

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

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

show more ...