Changes in TestFixIts.py

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

Thu, 21 Nov 2024 23:37:04 +0000

[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. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

23a09b99313edb67d267a974be6cebfdfd97c7c8 - [lldb][Test] Remove some xfails for AArch64 Linux

Wed, 29 May 2024 10:25:19 +0000

[lldb][Test] Remove some xfails for AArch64 LinuxPR #92245 fixed these tests on Linux. They likely work on FreeBSD toobut 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. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

9c2468821ec51defd09c246fea4a47886fff8c01 - [lldb][test] Modernize asserts (#82503)

Wed, 21 Feb 2024 19:02:30 +0000

[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`. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Sat, 17 Feb 2024 04:58:50 +0000

[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. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Fri, 13 Oct 2023 17:06:50 +0000

[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 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

133c3eaac0a532380c3d6ad21a60da1490f51fb8 - Streamline expression parser error messages.

Fri, 09 Jun 2023 22:29:28 +0000

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: :1:3: use of undeclared identifier 'x' 1+x) ^This is distracting and as far as I can tell only exists to workaround the fact that the first "error: " is unconditionally injectedby CommandReturnObject. The solution is not very elegant, but theresult looks much better.(Partially addresses rdar://110492710)Differential Revision: https://reviews.llvm.org/D152590 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

2238dcc39358353cac21df75c3c3286ab20b8f53 - [NFC][Py Reformat] Reformat python files in lldb

Thu, 25 May 2023 15:48:57 +0000

[NFC][Py Reformat] Reformat python files in lldbThis is an ongoing series of commits that are reformatting our Pythoncode. Reformatting is done with `black` (23.1.0).If you end up having problems merging this commit because you have madechanges to a python file, the best way to handle that is to run `gitcheckout --ours ` and then reformat it with black.RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-styleDifferential revision: https://reviews.llvm.org/D151460 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

dd5c5f72e00dca0e2458139fec09b1a715cfb238 - Make sure Target::EvaluateExpression() passes up an error instead of silently dropping it.

Fri, 14 Oct 2022 23:45:01 +0000

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.cppindex 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 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Tue, 30 Aug 2022 13:28:14 +0000

Reland "[lldb] Use just-built libcxx for tests when available"This commit improves upon cc0b5ebf7fc8, which added support forspecifying which libcxx to use when testing LLDB. That patch honoredrequests 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'slibrary (USE_SYSTEM_STDLIB=1).3. A path to libcxx was either provided by the user through CMake flagsor libcxx was built together with LLDB.Condition (2) is new and introduced in this patch in order to supporttests that are either:* Cross-platform (such as API/macosx/macCatalyst andAPI/tools/lldb-server). The just-built libcxx is usually not built forplatforms other than the host's.* Cross-language (such as API/lang/objc/exceptions). In this case, theObjective C runtime throws an exceptions that always goes through thesystem's libcxx, instead of the just built libcxx. Fixing this wouldrequire either changing the install-name of the just built libcxx in Macsystems, or tuning the DYLD_LIBRARY_PATH variable at runtime.Some other tests exposes limitations of LLDB when running with a debugstandard library. TestDbgInfoContentForwardLists had an assertionremoved, as it was checking for buggy LLDB behavior (which nowcrashes). TestFixIts had a variable renamed, as the old name clasheswith a standard library name when debug info is present. This is a knownissue: https://github.com/llvm/llvm-project/issues/34391.For `TestSBModule`, the way the "main" module is found was changed tolook for the "a.out" module, instead of relying on the index being 0. Insome systems, the index 0 is dyld when a custom standard library isused.Differential Revision: https://reviews.llvm.org/D132940 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Thu, 08 Sep 2022 18:37:46 +0000

Revert "[lldb] Use just-built libcxx for tests when available"This reverts commit c38eeecbc7d929c9601f2189214a7a90d3982a47. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Tue, 30 Aug 2022 13:28:14 +0000

[lldb] Use just-built libcxx for tests when availableThis commit improves upon cc0b5ebf7fc8, which added support forspecifying which libcxx to use when testing LLDB. That patch honoredrequests 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'slibrary (USE_SYSTEM_STDLIB=1).3. A path to libcxx was either provided by the user through CMake flagsor libcxx was built together with LLDB.Condition (2) is new and introduced in this patch in order to supporttests that are either:* Cross-platform (such as API/macosx/macCatalyst andAPI/tools/lldb-server). The just-built libcxx is usually not built forplatforms other than the host's.* Cross-language (such as API/lang/objc/exceptions). In this case, theObjective C runtime throws an exceptions that always goes through thesystem's libcxx, instead of the just built libcxx. Fixing this wouldrequire either changing the install-name of the just built libcxx in Macsystems, or tuning the DYLD_LIBRARY_PATH variable at runtime.Some other tests exposes limitations of LLDB when running with a debugstandard library. TestDbgInfoContentForwardLists had an assertionremoved, as it was checking for buggy LLDB behavior (which nowcrashes). TestFixIts had a variable renamed, as the old name clasheswith a standard library name when debug info is present. This is a knownissue: https://github.com/llvm/llvm-project/issues/34391.For `TestSBModule`, the way the "main" module is found was changed tolook for the "a.out" module, instead of relying on the index being 0. Insome systems, the index 0 is dyld when a custom standard library isused.Differential Revision: https://reviews.llvm.org/D132940 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

4cc8f2a017c76af25234afc7c380550e9c93135c - [lldb][tests] Automatically call compute_mydir (NFC)

Fri, 17 Jun 2022 00:38:47 +0000

[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 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

fbaf36721783c3bcbd45f81294e6980eaef165e4 - [lldb] Show fix-it applied even if expression didn't evaluate succesfully

Thu, 16 Sep 2021 19:26:49 +0000

[lldb] Show fix-it applied even if expression didn't evaluate succesfullyIf we applied a fix-it before evaluating an expression and thatexpression didn't evaluate correctly, we should still tell users aboutthe fix-it we applied since that may be the reason why it didn't workcorrectly.Differential Revision: https://reviews.llvm.org/D109908 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

25bf137b1ea33ff9c76834f44b10f4e1ae677d5e - Also display the underlying error message when displaying a fixit

Tue, 27 Apr 2021 17:38:51 +0000

Also display the underlying error message when displaying a fixitWhen the user running LLDB with default settings sees the fixitnotification it means that the auto-applied fixit didn't work. Thispatch shows the underlying error message instead of just the fixit tomake it easier to understand what the error in the expression was.Differential Revision: https://reviews.llvm.org/D101333 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Wed, 03 Mar 2021 14:57:51 +0000

[lldb] [test] Update XFAILs for FreeBSD/aarch64 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

35674976f09ec99e74d0d28b4a64b6bce360c128 - [lldb/Test] Introduce "assertSuccess"

Mon, 29 Jun 2020 11:51:46 +0000

[lldb/Test] Introduce "assertSuccess"Summary:A lot of our tests do 'self.assertTrue(error.Success()'. The problemwith that is that when this fails, it produces a completely uselesserror message (False is not True) and the most important piece ofinformation -- 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 itassertSuccess solves these problems by taking the entire SBError objectas an argument. If the operation was unsuccessful, it can format areasonable error message itself. The function still accepts a "msg"argument, which can include any additional context, but this context nowdoes not need to include the error message.To demonstrate usage, I replace a number of existing assertTrueassertions with the new function. As this process is not easilyautomatable, I have just manually updated a representative sample. Insome cases, I did not update the code to use assertSuccess, but I wentfor even higher-level assertion apis (runCmd, expect_expr), as these areeven shorter, and can produce even better failure messages.Reviewers: teemperor, JDevlieghereSubscribers: arphaman, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D82759 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Sat, 18 Apr 2020 06:32:12 +0000

[lldb] [testsuite] Fix TestFixIts.py on LinuxSince D77214 there is a testsuite regression for TestFixIts.pyon 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 debugsymbols and there exists a 'd' symbol: (gdb) p d $1 = {i = {0, 1076887552}, d = 16} (gdb) p &d $2 = (const number *) 0x7ffff78e8bc0 (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 List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

02d152bb1b63e1f5ebdf502a8b8c8c99103a5e75 - [lldb] Make some asserts in TestFixIts more expressive

Fri, 10 Apr 2020 17:16:33 +0000

[lldb] Make some asserts in TestFixIts more expressive List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

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

Fri, 10 Apr 2020 10:45:30 +0000

[lldb] Refactor TestFixIts so that most of it can run on aarch64-linuxThe 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-linuxbut 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 coversthe part of the test that was added D77214. List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py

2a436a07ae9749ed4d3f42c0d1e660eb4f7ca6e8 - Mark TestFixIts.py xfail for LLDB AArch64/Linux

Tue, 07 Apr 2020 10:59:05 +0000

Mark TestFixIts.py xfail for LLDB AArch64/Linux List of files: /llvm-project/lldb/test/API/commands/expression/fixits/TestFixIts.py