[LLDB] Fix TestConvenienceVariables.test AArch64/Windows

This patch fixes TestConvenienceVariables.test for AArch64 Windows.
Clang/LLD was unable to find printf apparently available as a macro
defin

[LLDB] Fix TestConvenienceVariables.test AArch64/Windows

This patch fixes TestConvenienceVariables.test for AArch64 Windows.
Clang/LLD was unable to find printf apparently available as a macro
definition in stdio.h.

show more ...

[lldb][bindings] Implement __repr__ instead of __str__

When using the `script` Python repl, SB objects are printed in a way that gives
the 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 gives
the 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 they
implement `__str__`, a more detailed output can be had by `print`ing the
object, 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 to
remember to wrap in `print()`. If that isn't enough motivation, consider the
case where your Python expression results in a list of SB objects, in that case
you'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 so
that they could be `eval`'d, however for typical lldb usage, I can't think of a
motivating 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 SB
object, 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

show more ...

Revert "[TestConvienceVariable] Clean the directory before running the test."

This reverts commit 9bce9d2d65e2462140597f71a8247750b837094c, as
it breaks the bots.

[TestConvienceVariable] Clean the directory before running the test.

[lldb/Test] Try to appease the Windows bot

In TestConvenienceVariables I changed %t from a file to a directory.
This tripped up mkdir which can't deal with an existing file at the
given location. In

[lldb/Test] Try to appease the Windows bot

In TestConvenienceVariables I changed %t from a file to a directory.
This tripped up mkdir which can't deal with an existing file at the
given location. In order to solve this issue on the bots I added an
`rm -rf %t` statement, but now the Windows bot complains that "This
function is not supported on this system".

If you never ran the test suite wit this temporary workaround, the test
might fail. If this happens please remove what %t expands to in the lit
output and rerun the test.

show more ...

[lldb/Test] Remove old binary created by TestConvenienceVariables

On a dirty build directory the new mkdir fails because the file already
exists and is not a directory.

[lldb/Test] Make TestConvenienceVariables more strict

This test was passing even when the output of lldb.target was empty.
I've made the test more strict by checking explicitly for the target
name a

[lldb/Test] Make TestConvenienceVariables more strict

This test was passing even when the output of lldb.target was empty.
I've made the test more strict by checking explicitly for the target
name and by using CHECK-NEXT lines.

show more ...

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

The original patch got reverted because it broke `check-lldb` on a clean
build. This fixes that.

llvm-svn: 374201

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

LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is

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

LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.

The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.

This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding 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 test
suites.

Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.

Differential revision: https://reviews.llvm.org/D68606

llvm-svn: 374184

show more ...