[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 ...
[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) s
[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<lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> >```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 <expr>]`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
Add support for XFAILing a test based on a setting.This is analogous to the skipping mechanism introduced inhttps://reviews.llvm.org/D75864
Add a decorator option to skip tests based on a default setting.This patch allows skipping a test based on a default setting, which isuseful when running the testsuite in different "modes" based o
Add a decorator option to skip tests based on a default setting.This patch allows skipping a test based on a default setting, which isuseful when running the testsuite in different "modes" based on adefault setting. This is a feature I need for the Swift testsuite, butI think it's generally useful.Differential Revision: https://reviews.llvm.org/D75864
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdi
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151