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