[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-

[lldb] Move ValueObject into its own library (NFC) (#113393)

ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.

The header includes were updated with the following command:

```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```

show more ...

[lldb] Make only one function that needs to be implemented when searching for types (#74786)

This patch revives the effort to get this Phabricator patch into
upstream:

https://reviews.llvm.org/D

[lldb] Make only one function that needs to be implemented when searching for types (#74786)

This patch revives the effort to get this Phabricator patch into
upstream:

https://reviews.llvm.org/D137900

This patch was accepted before in Phabricator but I found some
-gsimple-template-names issues that are fixed in this patch.

A fixed up version of the description from the original patch starts
now.

This patch started off trying to fix Module::FindFirstType() as it
sometimes didn't work. The issue was the SymbolFile plug-ins didn't do
any filtering of the matching types they produced, and they only looked
up types using the type basename. This means if you have two types with
the same basename, your type lookup can fail when only looking up a
single type. We would ask the Module::FindFirstType to lookup "Foo::Bar"
and it would ask the symbol file to find only 1 type matching the
basename "Bar", and then we would filter out any matches that didn't
match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it
would work, but if it found "Baz::Bar" first, it would return only that
type and it would be filtered out.

Discovering this issue lead me to think of the patch Alex Langford did a
few months ago that was done for finding functions, where he allowed
SymbolFile objects to make sure something fully matched before parsing
the debug information into an AST type and other LLDB types. So this
patch aimed to allow type lookups to also be much more efficient.

As LLDB has been developed over the years, we added more ways to to type
lookups. These functions have lots of arguments. This patch aims to make
one API that needs to be implemented that serves all previous lookups:

- Find a single type
- Find all types
- Find types in a namespace

This patch introduces a `TypeQuery` class that contains all of the state
needed to perform the lookup which is powerful enough to perform all of
the type searches that used to be in our API. It contain a vector of
CompilerContext objects that can fully or partially specify the lookup
that needs to take place.

If you just want to lookup all types with a matching basename,
regardless of the containing context, you can specify just a single
CompilerContext entry that has a name and a CompilerContextKind mask of
CompilerContextKind::AnyType.

Or you can fully specify the exact context to use when doing lookups
like: CompilerContextKind::Namespace "std"
CompilerContextKind::Class "foo"
CompilerContextKind::Typedef "size_type"

This change expands on the clang modules code that already used a
vector<CompilerContext> items, but it modifies it to work with
expression type lookups which have contexts, or user lookups where users
query for types. The clang modules type lookup is still an option that
can be enabled on the `TypeQuery` objects.

This mirrors the most recent addition of type lookups that took a
vector<CompilerContext> that allowed lookups to happen for the
expression parser in certain places.

Prior to this we had the following APIs in Module:

```
void
Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeList &types);

void
Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeMap &types);

void Module::FindTypesInNamespace(ConstString type_name,
const CompilerDeclContext &parent_decl_ctx,
size_t max_matches, TypeList &type_list);
```

The new Module API is much simpler. It gets rid of all three above
functions and replaces them with:

```
void FindTypes(const TypeQuery &query, TypeResults &results);
```
The `TypeQuery` class contains all of the needed settings:

- The vector<CompilerContext> that allow efficient lookups in the symbol
file classes since they can look at basename matches only realize fully
matching types. Before this any basename that matched was fully realized
only to be removed later by code outside of the SymbolFile layer which
could cause many types to be realized when they didn't need to.
- If the lookup is exact or not. If not exact, then the compiler context
must match the bottom most items that match the compiler context,
otherwise it must match exactly
- If the compiler context match is for clang modules or not. Clang
modules matches include a Module compiler context kind that allows types
to be matched only from certain modules and these matches are not needed
when d oing user type lookups.
- An optional list of languages to use to limit the search to only
certain languages

The `TypeResults` object contains all state required to do the lookup
and store the results:
- The max number of matches
- The set of SymbolFile objects that have already been searched
- The matching type list for any matches that are found

The benefits of this approach are:
- Simpler API, and only one API to implement in SymbolFile classes
- Replaces the FindTypesInNamespace that used a CompilerDeclContext as a
way to limit the search, but this only worked if the TypeSystem matched
the current symbol file's type system, so you couldn't use it to lookup
a type in another module
- Fixes a serious bug in our FindFirstType functions where if we were
searching for "foo::bar", and we found a "baz::bar" first, the basename
would match and we would only fetch 1 type using the basename, only to
drop it from the matching list and returning no results

show more ...

[lldb] Guarantee the lifetimes of all strings returned from SBAPI

LLDB should guarantee that the strings returned by SBAPI methods
live forever. I went through every method that returns a string and

[lldb] Guarantee the lifetimes of all strings returned from SBAPI

LLDB should guarantee that the strings returned by SBAPI methods
live forever. I went through every method that returns a string and made
sure that it was added to the ConstString StringPool before returning if
it wasn't obvious that it was already doing so.
I've also updated the docs to document this behavior.

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

show more ...

Revert "[lldb] Remove timer from SBModule copy ctor"

This reverts commit 84c6129c943135e2c32b9254f08d0a2e7b21116a.

[lldb] Remove timer from SBModule copy ctor

The SBModule copy constructor has fast execution, and is high firing. Fast and
frequent functions are not good candidates for timers.

Differential Revisi

[lldb] Remove timer from SBModule copy ctor

The SBModule copy constructor has fast execution, and is high firing. Fast and
frequent functions are not good candidates for timers.

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

show more ...

Make CompilerType safe

When a process gets restarted TypeSystem objects associated with it
may get deleted, and any CompilerType objects holding on to a
reference to that type system are a use-after

Make CompilerType safe

When a process gets restarted TypeSystem objects associated with it
may get deleted, and any CompilerType objects holding on to a
reference to that type system are a use-after-free in waiting. Because
of the SBAPI, we don't have tight control over where CompilerTypes go
and when they are used. This is particularly a problem in the Swift
plugin, where the scratch TypeSystem can be restarted while the
process is still running. The Swift plugin has a lock to prevent
abuse, but where there's a lock there can be bugs.

This patch changes CompilerType to store a std::weak_ptr<TypeSystem>.
Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by
introducing a wrapper class CompilerType::WrappedTypeSystem that has a
dyn_cast_or_null() method. The only sites that need to know about the
weak pointer implementation detail are the ones that deal with
creating TypeSystems.

rdar://101505232

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

show more ...

[lldb] Use value_or instead of getValueOr (NFC)

[lldb/API] Add ability to check if module is backed by a file on disk

This patch introduces a new SBAPI method: `SBModule::IsFileBacked`

As the name suggests, it tells the user if the module's obje

[lldb/API] Add ability to check if module is backed by a file on disk

This patch introduces a new SBAPI method: `SBModule::IsFileBacked`

As the name suggests, it tells the user if the module's object file is
on disk or in memory.

rdar://68538278

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb] Decouple instrumentation from the reproducers

Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

Differential

[lldb] Decouple instrumentation from the reproducers

Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

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

show more ...

[lldb] Remove LLDB_RECORD_RESULT macro

[lldb] Remove reproducer instrumentation

This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists

[lldb] Remove reproducer instrumentation

This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

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

show more ...

[API] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb] Use a struct to pass function search options to Module::FindFunction

Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct

[lldb] Use a struct to pass function search options to Module::FindFunction

Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct with named fields
instead.

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

show more ...

[lldb] Add missing LLDB_REGISTER for GarbageCollectAllocatedModules

Add the missing LLDB_REGISTER_STATIC_METHOD macro and format the file.

[lldb] Add SBModule::GarbageCollectAllocatedModules and clear modules after each test run

Right now the only places in the SB API where lldb:: ModuleSP instances are
destroyed are in SBDebugger::Mem

[lldb] Add SBModule::GarbageCollectAllocatedModules and clear modules after each test run

Right now the only places in the SB API where lldb:: ModuleSP instances are
destroyed are in SBDebugger::MemoryPressureDetected (where it's just attempted
but not guaranteed) and in SBDebugger::DeleteTarget (which will be removed in
D83933). Tests that directly create an lldb::ModuleSP and never create a target
therefore currently leak lldb::Module instances. This triggers the sanity checks
in lldbtest that make sure that the global module list is empty after a test.

This patch adds SBModule::GarbageCollectAllocatedModules as an explicit way to
clean orphaned lldb::ModuleSP instances. Also we now start calling this method
at the end of each test run and move the sanity check behind that call to make
this work. This way even tests that don't create targets can pass the sanity
check.

This fixes TestUnicodeSymbols.py when D83865 is applied (which makes that the
sanity checks actually fail the test).

Reviewed By: JDevlieghere

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

show more ...

[lldb/Test] Assert that no targets or modules remain after a test completes.

The reproducer intentionally leak every object allocated during replay,
which means that modules never get orphaned. If t

[lldb/Test] Assert that no targets or modules remain after a test completes.

The reproducer intentionally leak every object allocated during replay,
which means that modules never get orphaned. If this were to happen for
another reason, we might not be testing what we think we are. Assert
that there are no targets left at the end of a test and that the global
module cache is empty in the non-reproducer scenario.

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

show more ...

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers

Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seem

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers

Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).

This moves all APIs to use references and gets rid of all the nullptr checks and conversions.

Reviewers: labath, mib, shafik

Reviewed By: labath, shafik

Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb] Replace empty ctor en dtor bodies with =default (NFC)

Use = default instead of empty constructor and destructor bodies in the
API layer.

[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] Migrate to raw_ostream in Module::GetDescription

[lldb][NFC] Allow range-based for-loops on VariableList

Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possib

[lldb][NFC] Allow range-based for-loops on VariableList

Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.

Reviewers: labath, jdoerfert

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

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

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

SymbolVendor: Remove passthrough methods

After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to

SymbolVendor: Remove passthrough methods

After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().

llvm-svn: 368001

show more ...

Remove SymbolVendor::GetSymtab

Summary:
This patch removes the GetSymtab method from the SymbolVendor, which is
a no-op as it's implementation just forwards to the relevant SymbolFile.
Instead it cr

Remove SymbolVendor::GetSymtab

Summary:
This patch removes the GetSymtab method from the SymbolVendor, which is
a no-op as it's implementation just forwards to the relevant SymbolFile.
Instead it creates a Module::GetSymtab, which calls the SymbolFile
method directly.

All callers have been updated to use the Module method directly instead
of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced
intentation in a lot of deeply nested code.

Reviewers: clayborg, JDevlieghere, jingham

Subscribers: lldb-commits

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

llvm-svn: 367820

show more ...