[lldb] Automatically unwrap parameter packs in template argument accessors

When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of th

[lldb] Automatically unwrap parameter packs in template argument accessors

When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.

This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.

A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.

The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.

The original patch was written by Fred Riss almost 4 years ago.

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

(cherry picked from commit b706f56133a77f9d7c55270ac24ff59e6fce3fa4)

show more ...

[lldb][NFC] Give CompilerType's IsArrayType/IsVectorType/IsBlockPointerType out-parameters default values

We already do this for most functions that have out-parameters, so let's do
the same here an

[lldb][NFC] Give CompilerType's IsArrayType/IsVectorType/IsBlockPointerType out-parameters default values

We already do this for most functions that have out-parameters, so let's do
the same here and avoid all the `nullptr, nullptr, nullptr` in every call.

show more ...

[lldb] Add SBType::GetEnumerationIntegerType method

Add a method for getting the enumeration underlying type.

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

[lldb] Add SBType::IsScopedEnumerationType method

Add a method to check if the type is a scoped enumeration (i.e. "enum
class/struct").

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

[lldb] Remove unused IsFunctionType is_variadic_ptr parameter (NFC)

`is_variadic_ptr` is unused.

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

[lldb][NFC] Remove stride parameter from GetArrayElementType

This parameter isn't used anywhere in LLDB nor the Swift downstream branch. It
also doesn't really fit into the TypeSystem APIs that usua

[lldb][NFC] Remove stride parameter from GetArrayElementType

This parameter isn't used anywhere in LLDB nor the Swift downstream branch. It
also doesn't really fit into the TypeSystem APIs that usually don't return
additional related functionality via some output parameters. Also the
implementations already states that the calculated value there is wrong.

Let's remove it. If we need this functionality at some point then Swift's much
nicer `GetByteStride` function seems like the way to go.

Reviewed By: aprantl

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

show more ...

Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)

This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call

Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)

This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.

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

show more ...

[lldb][NFC] Remove unused DEPTH_INCREMENT in CompilerType.cpp

Allow lldb-test to combine -find with -dump-clang-ast

This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
add

Allow lldb-test to combine -find with -dump-clang-ast

This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.

The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.

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

show more ...

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarch

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.

rdar://problem/59634380

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

show more ...

Revert "Preserve the owning module information from DWARF in the synthesized AST"

This reverts commit 4354dfbdf5c8510a7ddff10ae67a28e16cf7cc79 while investigating bot fallout.

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarch

Preserve the owning module information from DWARF in the synthesized AST

Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
sets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

rdar://problem/59634380

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

show more ...

Add a verification mechanism to CompilerType.

Badly-written code can combine an unrelated TypeSystem and opaque type
pointer into a CompilerType. This is particularly an issue in
swift-lldb. This pa

Add a verification mechanism to CompilerType.

Badly-written code can combine an unrelated TypeSystem and opaque type
pointer into a CompilerType. This is particularly an issue in
swift-lldb. This patch adds an assertion mechanism that catches these
kinds of mistakes early. Because this is an assertion-only code path
there is not cost for release builds.

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

show more ...

[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType

Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the

[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType

Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.

show more ...

[lldb] Move implementation of GetDisplayName to TypeSystem class

CompilerType doesn't implement logic.

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Simplify CompilerType constructors/destructors and fix unused variable warning

CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code.

[lldb][NFC] Simplify CompilerType constructors/destructors and fix unused variable warning

CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code. This also allows Clang to emit unused variable warnings
for CompilerType, so I also removed one unused variable that otherwise causes -Werror
builds to fail.

show more ...

[lldb] Support for DWARF-5 atomic types

Summary:
This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement A

[lldb] Support for DWARF-5 atomic types

Summary:
This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate.

Thanks Pavel for writing the test case.

Reviewers: labath, aprantl, shafik

Reviewed By: labath

Subscribers: jfb, abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove unused CompilerType memory functions

Summary:
All these functions are unused from what I can see. Unless I'm missing something here, this code
can go the way of the Dodo.

Reviewe

[lldb][NFC] Remove unused CompilerType memory functions

Summary:
All these functions are unused from what I can see. Unless I'm missing something here, this code
can go the way of the Dodo.

Reviewers: labath

Reviewed By: labath

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[Symbol] Decouple clang from CompilerType

Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.

Differential R

[Symbol] Decouple clang from CompilerType

Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.

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

llvm-svn: 368741

show more ...

[CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.

llvm-svn: 368620

[Symbol] GetTypeBitAlign() should return None in case of failure.

Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.

Reviewers: xiaobai, compnerd

Subscribers:

[Symbol] GetTypeBitAlign() should return None in case of failure.

Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.

Reviewers: xiaobai, compnerd

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 368614

show more ...

Revert "[CompilerType] Simplify the interface a bit more.."

There's actually a test downstream that fails with this.
I think we can still get rid of it, but I need to do some work
there first.

llvm

Revert "[CompilerType] Simplify the interface a bit more.."

There's actually a test downstream that fails with this.
I think we can still get rid of it, but I need to do some work
there first.

llvm-svn: 367963

show more ...

[CompilerType] Simplify the interface a bit more..

Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without d

[CompilerType] Simplify the interface a bit more..

Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without dynamic counterpart] don't carry a lot
of value. Since then, the formatters and dynamic type resolution
has been rewritten, and we employ different solutions. This function
is unused here too, so let's get read of it.

<rdar://problem/36377967>

Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 367957

show more ...

[CompilerType] Remove an unused function.

Summary:
This simplifies the interface, as I'm trying to understand how
we can upstream swift support.

<rdar://problem/36377967>

Reviewers: teemperor, JDe

[CompilerType] Remove an unused function.

Summary:
This simplifies the interface, as I'm trying to understand how
we can upstream swift support.

<rdar://problem/36377967>

Reviewers: teemperor, JDevlieghere, xiaobai, compnerd, friss

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 367946

show more ...