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

Use true/false instead of 1/0 (NFC)

Identified by modernize-use-bool-literals.

[lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage

When assertions are turned off, the `llvm::Error` value created at the
start of this function is overwritten using the move-as

[lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage

When assertions are turned off, the `llvm::Error` value created at the
start of this function is overwritten using the move-assignment
operator, but the success value is never checked. Whenever a TypeSystem
cannot be found or created, this can lead to lldb core dumping with:

Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).

Fix this by not creating a `llvm::Error` value in advance, and directly
returning the result of `llvm::make_error` instead, whenever an error is
encountered.

See also: <https://bugs.freebsd.org/253881> and
<https://bugs.freebsd.org/257829>.

Reviewed By: teemperor

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy

[lldb] Use C++11 default member initializers

This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

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

show more ...

[lldb] Fix use of undefined type 'lldb_private::UtilityFunction'

We were returning the default constructed unique_pointer from
TypeSystem.h for which the compiler does not have a definition. Move th

[lldb] Fix use of undefined type 'lldb_private::UtilityFunction'

We were returning the default constructed unique_pointer from
TypeSystem.h for which the compiler does not have a definition. Move the
implementation into the cpp file.

show more ...

[lldb] Deduplicate copy-pasted TypeSystemMap::GetTypeSystemForLanguage

There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage`
which are both identical beside one taking a `Modul

[lldb] Deduplicate copy-pasted TypeSystemMap::GetTypeSystemForLanguage

There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage`
which are both identical beside one taking a `Module` and one taking a `Target`
(and then passing that argument to the `TypeSystem::CreateInstance` function).

This merges both implementations into one function with a lambda that wraps the
different calls to `TypeSystem::CreateInstance`.

Reviewed By: #lldb, JDevlieghere

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

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/Symbol] Use StringRef ctor to prevent incorrect overload

Use the StringRef constructor instead of toStringRef so we don't end up
with the wrong overload (llvm::toStringRef(bool)).

Fixes PR447

[lldb/Symbol] Use StringRef ctor to prevent incorrect overload

Use the StringRef constructor instead of toStringRef so we don't end up
with the wrong overload (llvm::toStringRef(bool)).

Fixes PR44736

show more ...

[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] 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] Move TypeSystem RTTI to static variable to remove swift reference

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-lan

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

This reapplies r369690 with a previously missing constructor for LanguageSet.

llvm-svn: 369710

show more ...

Revert Extend FindTypes with CompilerContext to allow filtering by language.

This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f)

llvm-svn: 369702

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-lan

Extend FindTypes with CompilerContext to allow filtering by language.

This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

llvm-svn: 369690

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

[Symbol] Use llvm::Expected when getting TypeSystems

Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This mea

[Symbol] Use llvm::Expected when getting TypeSystems

Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.

Reviewers: JDevlieghere, davide, compnerd

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 367360

show more ...

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, s

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

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

llvm-svn: 355553

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD

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

llvm-svn: 349215

show more ...

Provide a default implementation of TypeSystem::GetNumTemplateArguments

... and remove the dummy implementations from the languages that do not
support it.

llvm-svn: 341006