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 |
|
#
0fc57866 |
| 14-Feb-2024 |
Jordan Rupprecht <rupprecht@google.com> |
[lldb][test] Remove expectedFailureIfFn (#81703)
Switching to modern `unittest` in
5b386158aacac4b41126983a5379d36ed413d0ea needs xfail annotations to be
known prior to test running. In contrast,
[lldb][test] Remove expectedFailureIfFn (#81703)
Switching to modern `unittest` in
5b386158aacac4b41126983a5379d36ed413d0ea needs xfail annotations to be
known prior to test running. In contrast, skipping can happen at any
time, even during test execution.
Thus, `expectedFailureIfFn` inherently doesn't work. Either we eagerly
evaluate the function and use `expectedFailureIf` instead, or we use a
skip annotation to lazily evaluate the function and potentially skip the
test right before it starts.
- For `expectedFailureAndroid`, the intent seems to be that certain
tests _should_ work on android, but don't. Thus, xfail is appropriate,
to ensure the test is re-enabled once those bugs are ever fixed.
- For the other uses in individual tests, those generally seem to be
cases where the test environment doesn't support the setup required by
the test, and so it isn't meaningful to run the test at all. For those,
a drop-in replacement to `skipTestIfFn` works.
show more ...
|
Revision tags: 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 ...
|
Revision tags: llvmorg-14.0.5 |
|
#
ce825e46 |
| 08-Jun-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[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 ...
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
065e3c9a |
| 08-Apr-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Skip more tests that don't make sense to run remotely
Skip another batch of tests that don't really make sense to run remotely.
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
779bbbf2 |
| 12-Feb-2022 |
Dave Lee <davelee.com@gmail.com> |
[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 ...
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
d1e9514a |
| 29-Oct-2021 |
Jim Ingham <jingham@apple.com> |
To avoid the obvious problem, use a different port...
There's another test that opens an hard-coded port to talk to debugserver (TestPlatformSDK.py). Make sure this port and the one in that other t
To avoid the obvious problem, use a different port...
There's another test that opens an hard-coded port to talk to debugserver (TestPlatformSDK.py). Make sure this port and the one in that other test are different to avoid that potential conflict.
show more ...
|
#
e655769c |
| 28-Oct-2021 |
Jim Ingham <jingham@apple.com> |
Fix a bug in Launch when using an async debugger & remote platform.
We weren't setting the listener back to the unhijacked one in this case, so that a continue after the stop fails. It thinks the p
Fix a bug in Launch when using an async debugger & remote platform.
We weren't setting the listener back to the unhijacked one in this case, so that a continue after the stop fails. It thinks the process is still running. Also add tests for this behavior.
Differential Revision: https://reviews.llvm.org/D112747
show more ...
|