[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 ...

[lldb][test] Skip import-std-module/vector tests

These tests have begun failing starting with commit
`69a6417406a1b0316a1fa6aeb63339d0e1d2abbd`, which
added a new `import` to `ASTNodeImporter::Visit

[lldb][test] Skip import-std-module/vector tests

These tests have begun failing starting with commit
`69a6417406a1b0316a1fa6aeb63339d0e1d2abbd`, which
added a new `import` to `ASTNodeImporter::VisitTypedefType`.
This trips an assertion in following way:
1. When creating a persistent variable for the result we call `CopyType`
(in `DeportType`) under a `CompleteTagDeclsScope` (which is supposed to complete all
decls newly imported in the `CopyType` call).
2. During `CopyType` we call `ASTNodeImporter::VisitTypedefType`
3. This now has a second import call on the desugared type
4. In `ASTImporterDelegate::ImportImpl` we will now try to import a decl
that we originally got from the `std` module (which means it has no valid origin).
But since we’re doing this under a CompleteTagDeclsScope, the
`NewDeclListener::NewDeclImported` adds the decl to the list of decls to
complete after the `CopyType` call. But this list shouldn’t contain decls
with invalid origins because we assert this in `~CompleteTagDeclsScope`, which
is where the tests crash.

We suspect that we previously didn’t see this assert trigger because by the time
we create the result variable we are using an AST whose decls all have
a valid debug-info origin (constructed with the help of the std module).
So we never expected decls from modules to be imported under
`CompleteTagDeclsScope` without a m_sema available (which is the case by
the time we get to `DeportType`). Since there is no `m_sema` available,
`CxxModuleHandler::Import` trivially returns and the decls don’t get added
to the `m_decls_to_ignore` list and count as "newly imported decls".

Skip this test for now until we have a fix or the origin tracking gets
refactored (see https://reviews.llvm.org/D101950).

Differential Revision: https://reviews.llvm.org/D135178

show more ...

[lldb][test] Remove failing ValueCheck on deprecated libcxx entity

A recent libcxx change renamed all internal variables starting with
`__`. As such, `std::reverse_iterator::__t` was renamed to
`std

[lldb][test] Remove failing ValueCheck on deprecated libcxx entity

A recent libcxx change renamed all internal variables starting with
`__`. As such, `std::reverse_iterator::__t` was renamed to
`std::reverse_iterator::__t_`. This breaks the `import-std-module`
tests with newer libcxx versions. Since this variable is deprecated
in libcxx anyway, this patch simply removes the explicit `ValueCheck`
on the variable name. We don't lose any interesting test-case here
since the purpose of the test is to see if we can call functions
from the `std` module.

We can now re-enable the tests on Darwin for all buildbot Clang
compiler variants.

Differential Revision: https://reviews.llvm.org/D134727

show more ...

Temporarily XFAIL libcxx tests.

These tests started failing on green dragon after a configuration change that compiles tests using the just-built libcxx. We may need to force the system libcxx here,

Temporarily XFAIL libcxx tests.

These tests started failing on green dragon after a configuration change that compiles tests using the just-built libcxx. We may need to force the system libcxx here, or change LLDB to import the std module from the just-built libcxx, too.

show more ...

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which go

[clang] Implement ElaboratedType sugaring for types written bare

Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.

The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.

An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.

---

Troubleshooting list to deal with any breakage seen with this patch:

1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.

2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.

3) This patch could expose a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.

4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.

5) It could be a bug in this patch perhaps.

Let me know if you need any help!

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D112374

show more ...

[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/test] Fix std-module vector tests to work with both kinds of vector layouts

D112976 changed the layout and 0d62e31c45 andjusted the test
expectations to match.

This patch changes the tests to

[lldb/test] Fix std-module vector tests to work with both kinds of vector layouts

D112976 changed the layout and 0d62e31c45 andjusted the test
expectations to match.

This patch changes the tests to expect both versions, so that one can
run the test suite against older libc++ versions as well.

show more ...

[LLDB][NFC] Fix test that broke due to libc++ std::vector changes

D112976 moved most of the guts of __vector_base into vector, this broke
some LLDB tests by changing the result types that LLDB sees.

[LLDB][NFC] Fix test that broke due to libc++ std::vector changes

D112976 moved most of the guts of __vector_base into vector, this broke
some LLDB tests by changing the result types that LLDB sees. This updates
the test to reflect the new structure.

show more ...

[lldb][import-std-module] Add a test for typedef'd std types

[ASTImporter] Import the default argument of TemplateTypeParmDecl

The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl defa

[ASTImporter] Import the default argument of TemplateTypeParmDecl

The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl default arguments. Otherwise this is simply importing the
default arguments.

Also updates several LLDB tests that now as intended omit the default template
arguments of several std templates.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D92103

show more ...

[lldb] Reference STL types in import-std-module tests

With the recent patches to the ASTImporter that improve template type importing
(D87444), most of the import-std-module tests can now finally im

[lldb] Reference STL types in import-std-module tests

With the recent patches to the ASTImporter that improve template type importing
(D87444), most of the import-std-module tests can now finally import the
type of the STL container they are testing. This patch removes most of the casts
that were added to simplify types to something the ASTImporter can import
(for example, std::vector<int>::size_type was casted to `size_t` until now).
Also adds the missing tests that require referencing the container type (for
example simply printing the whole container) as here we couldn't use a casting
workaround.

The only casts that remain are in the forward_list tests that reference
the iterator and the stack test. Both tests are still failing to import the
respective container type correctly (or crash while trying to import).

show more ...

[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/testcases
mkdi

[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/testcases
mkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}
mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runner
for 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; done
for 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; done
for 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, JDevlieghere

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71151

show more ...