Changes in convenience.in

c7a56af3072c2fa89f0968d7f00b22f7bff0812b - [lldb][bindings] Implement repr instead of str

Thu, 09 Jun 2022 15:37:02 +0000

[lldb][bindings] Implement __repr__ instead of __str__When using the `script` Python repl, SB objects are printed in a way that givesthe user no information. The simplest example is:```(lldb) script lldb.debugger >```This output comes from the Python repl printing the `repr()` of an object.None of the SB classes implement `__repr__`, and all print like the above.However, many (most?, all?) SB classes implement `__str__`. Because theyimplement `__str__`, a more detailed output can be had by `print`ing theobject, for example:```(lldb) script print(lldb.debugger)Debugger (instance: "debugger_1", id: 1)```For convenience, this change switches all SB classes that implement to`__str__` to instead implement `__repr__`. **The result is that `str()` and`repr()` will produce the same output**. This is because `str` calls `__repr__`for classes that have no `__str__` method.The benefit being that when writing a `script` invocation, you don't need toremember to wrap in `print()`. If that isn't enough motivation, consider thecase where your Python expression results in a list of SB objects, in that caseyou'd have to `map` or use a list comprehension like `[str(x) for x in ]`in order to see the details of the objects in the list.For reference, the docs for `repr` say:> repr(object)> Return a string containing a printable representation of an object. For> many types, this function makes an attempt to return a string that would> yield an object with the same value when passed to eval(); otherwise, the> representation is a string enclosed in angle brackets that contains the> name of the type of the object together with additional information often> including the name and address of the object. A class can control what this> function returns for its instances by defining a __repr__() method.and the docs for `__repr__` say:> object.__repr__(self)> Called by the repr() built-in function to compute the “official” string> representation of an object. If at all possible, this should look like a> valid Python expression that could be used to recreate an object with the> same value (given an appropriate environment). If this is not possible, a> string of the form <...some useful description...> should be returned. The> return value must be a string object. If a class defines __repr__() but not> __str__(), then __repr__() is also used when an “informal” string> representation of instances of that class is required.>> This is typically used for debugging, so it is important that the> representation is information-rich and unambiguous.Even if it were convenient to construct Python expressions for SB classes sothat they could be `eval`'d, however for typical lldb usage, I can't think of amotivating reason to do so. As it stands, the only action the docs say to do,that this change doesn't do, is wrap the `repr` string in `<>` angle brackets.An alternative implementation is to change lldb's python repl to apply `str()`to the top level result. While this would work well in the case of a single SBobject, it doesn't work for a list of SB objects, since `str([x])` uses `repr`to convert each list element to a string.Differential Revision: https://reviews.llvm.org/D127458 List of files: /llvm-project/lldb/test/Shell/Driver/Inputs/convenience.in

87aa9c9e4d41ed881453e2fab85b3d25f648bb55 - Re-land "[test] Split LLDB tests into API, Shell & Unit"

Wed, 09 Oct 2019 19:22:02 +0000

Re-land "[test] Split LLDB tests into API, Shell & Unit"The original patch got reverted because it broke `check-lldb` on a cleanbuild. This fixes that.llvm-svn: 374201 List of files: /llvm-project/lldb/test/Shell/Driver/Inputs/convenience.in

22314179f0660c172514b397060fd8f34b586e82 - [test] Split LLDB tests into API, Shell & Unit

Wed, 09 Oct 2019 16:38:47 +0000

[test] Split LLDB tests into API, Shell & UnitLLDB has three major testing strategies: unit tests, tests that exercisethe SB API though dotest.py and what we currently call lit tests. Thelater is rather confusing as we're now using lit as the driver for allthree types of tests. As most of this grew organically, the directorystructure in the LLDB repository doesn't really make this clear.The 'lit' tests are part of the root and among these tests there's aUnit and Suite folder for the unit and dotest-tests. This layout makesit impossible to run just the lit tests.This patch changes the directory layout to match the 3 testingstrategies, each with their own directory and their own configurationfile. This means there are now 3 directories under lit with 3corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests.Finally, there's still the `check-lldb` target that runs all three testsuites.Finally, this also renames the lit folder to `test` to match the LLVMrepository layout.Differential revision: https://reviews.llvm.org/D68606llvm-svn: 374184 List of files: /llvm-project/lldb/test/Shell/Driver/Inputs/convenience.in

Changes in convenience.in

c7a56af3072c2fa89f0968d7f00b22f7bff0812b - [lldb][bindings] Implement __repr__ instead of __str__

87aa9c9e4d41ed881453e2fab85b3d25f648bb55 - Re-land "[test] Split LLDB tests into API, Shell & Unit"

22314179f0660c172514b397060fd8f34b586e82 - [test] Split LLDB tests into API, Shell & Unit

c7a56af3072c2fa89f0968d7f00b22f7bff0812b - [lldb][bindings] Implement repr instead of str