Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

Revert "[lldb/PDB] Use the new line table constructor"

This reverts commit bb73210ba9f16c1516f564235c86cbddccd1bd6d due to
failures on the windows bot.

[lldb/PDB] Use the new line table constructor

The old method of adding line sequences one by one can easily go
quadratic if the sequences are not perfectly sorted. The equivalent
change in DWARF bro

[lldb/PDB] Use the new line table constructor

The old method of adding line sequences one by one can easily go
quadratic if the sequences are not perfectly sorted. The equivalent
change in DWARF brought a considerable improvement in line table
parsing. It is not clear if the same will be the case for PDB, but this
does bring us a step closer towards removing the dangerous API.

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][NFC] Rename ClangASTContext to TypeSystemClang

Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the Type

[lldb][NFC] Rename ClangASTContext to TypeSystemClang

Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).

I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.

Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai

Reviewed By: clayborg, labath, xiaobai

Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove all unnecessary includes for ClangASTSourceCommon.h

These files only need the definition of ClangASTMetadata (which was
previously in the ClangASTSourceCommon.h) or don't need the

[lldb][NFC] Remove all unnecessary includes for ClangASTSourceCommon.h

These files only need the definition of ClangASTMetadata (which was
previously in the ClangASTSourceCommon.h) or don't need the include at all.

show more ...

[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables

Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the fil

[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables

Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.

While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.

What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.

DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.

I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.

Reviewers: clayborg, JDevlieghere, jdoerfert

Subscribers: aprantl, lldb-commits

Tags: #lldb

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

show more ...

Replace bitfield in lldb::Type with byte-sized members. (NFC)

Due to alginment and packing using separate members takes up the same
amount of space, but makes it far less cumbersome to deal with it

Replace bitfield in lldb::Type with byte-sized members. (NFC)

Due to alginment and packing using separate members takes up the same
amount of space, but makes it far less cumbersome to deal with it in
constructors etc.

show more ...

Add RTTI support to the SymbolFile class hierarchy

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

Performance: Add a set of visited SymbolFiles to the other FindFiles variant.

This is basically the same bug as in r260434.

SymbolFileDWARF::FindTypes has exponential worst-case when digging
throug

Performance: Add a set of visited SymbolFiles to the other FindFiles variant.

This is basically the same bug as in r260434.

SymbolFileDWARF::FindTypes has exponential worst-case when digging
through dependency DAG of .pcm files because each object file and .pcm
file may depend on an already-visited .pcm file, which may again have
dependencies. Fixed here by carrying a set of already visited
SymbolFiles around.

rdar://problem/56993424

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

show more ...

Modernize the rest of the Find.* API (NFC)

This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous p

Modernize the rest of the Find.* API (NFC)

This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.

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

llvm-svn: 375160

show more ...

[NativePDB] Remove unused references to ClangASTImporter

llvm-svn: 374587

Remove size_t return parameter from FindTypes

In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.

Th

Remove size_t return parameter from FindTypes

In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.

This patch simply removes the size_t return parameter altogether —
it's not that useful.

rdar://problem/55500457

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

llvm-svn: 373344

show more ...

Remove unused "append" parameter from FindTypes API

I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTy

Remove unused "append" parameter from FindTypes API

I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTypes would yield only the very last set of results), but instead
of fixing it, removing it seemed like an even better option.

rdar://problem/54412692

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

llvm-svn: 373224

show more ...

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

Generalize FindTypes with CompilerContext to support fuzzy lookup

This patch generalizes the FindTypes with CompilerContext interface to
support looking up a type of unknown kind by name, as well as

Generalize FindTypes with CompilerContext to support fuzzy lookup

This patch generalizes the FindTypes with CompilerContext interface to
support looking up a type of unknown kind by name, as well as looking
up a type inside an unspecified submodule. These features are
motivated by the Swift branch, but are fully tested via unit tests and
lldb-test on llvm.org. Specifically, this patch adds an AnyModule and
an AnyType CompilerContext kind.

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

rdar://problem/54471165

llvm-svn: 369555

show more ...

[LLDB] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[LLDB] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

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

llvm-svn: 368933

show more ...

Add llvm-style RTTI to ObjectFile hierarchy

Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existi

Add llvm-style RTTI to ObjectFile hierarchy

Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.

This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
we could get away with not modeling them explicitly was because the
code was relying on magically knowing what will GetPluginName() return
for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
SymbolVendorELF to depend on ObjectFileELF), or at least don't
actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
don't depend on any other plugins

Reviewers: xiaobai, JDevlieghere, espindola

Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits

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

llvm-svn: 367413

show more ...

SymbolVendor: Remove the object file member variable

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
di

SymbolVendor: Remove the object file member variable

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 367392

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

SymbolVendor: Move locking into the Symbol Files

Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking

SymbolVendor: Move locking into the Symbol Files

Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.

Reviewers: clayborg, JDevlieghere, jingham, jdoerfert

Subscribers: aprantl, lldb-commits

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

llvm-svn: 367298

show more ...

SymbolVendor: Remove the type list member

Summary:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.

Since the only purpose of this list seems to

SymbolVendor: Remove the type list member

Summary:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.

Since the only purpose of this list seems to be to maintain an owning
reference to all the types a symbol file has created (items are only
ever added to the list, never retrieved), I remove the passthrough
functions in SymbolVendor and Module. I also tighten the interface of
the function (return a reference instead of a pointer, make it protected
instead of public).

Reviewers: clayborg, JDevlieghere, jingham

Subscribers: lldb-commits

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

llvm-svn: 366994

show more ...

SymbolVendor: Move compile unit handling into the SymbolFile class

Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->C

SymbolVendor: Move compile unit handling into the SymbolFile class

Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->CompileUnit mapping
(because of APIs like ParseCompileUnitAtIndex). However, the
SymbolVendor has remained as the thing responsible for caching created
units (which the SymbolFiles were calling via convoluted constructs like
"m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)").

This patch moves the responsibility of caching the units into the
SymbolFile class. It does this by moving the implementation of
SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the
equivalent SymbolFile functions. The SymbolVendor functions become just
a passthrough much like the rest of SymbolVendor.

The original implementations of SymbolFile::GetNumCompileUnits is moved
to "CalculateNumCompileUnits", and are made protected, as the "Get"
function is the external api of the class.
SymbolFile::ParseCompileUnitAtIndex is made protected for the same
reason.

This is the first step in removing the SymbolVendor indirection, as
proposed in
<http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After
removing all interesting logic from the SymbolVendor class, I'll proceed
with removing the indirection itself.

Reviewers: clayborg, jingham, JDevlieghere

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 366791

show more ...