[lldb] Make deep copies of Status explicit (NFC) (#107170)

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

[lldb] Expand background symbol download (#80890)

LLDB has a setting (symbols.enable-background-lookup) that calls
dsymForUUID on a background thread for images as they appear in the
current backtra

[lldb] Expand background symbol download (#80890)

LLDB has a setting (symbols.enable-background-lookup) that calls
dsymForUUID on a background thread for images as they appear in the
current backtrace. Originally, the laziness of only looking up symbols
for images in the backtrace only existed to bring the number of
dsymForUUID calls down to a manageable number.

Users have requesting the same functionality but blocking. This gives
them the same user experience as enabling dsymForUUID globally, but
without the massive upfront cost of having to download all the images,
the majority of which they'll likely not need.

This patch renames the setting to have a more generic name
(symbols.auto-download) and changes its values from a boolean to an
enum. Users can now specify "off", "background" and "foreground". The
default remains "off" although I'll probably change that in the near
future.

show more ...

Revert "[lldb] Expand background symbol lookup" (#81182)

Reverts llvm/llvm-project#80890

[lldb] Expand background symbol download (#80890)

LLDB has a setting (symbols.enable-background-lookup) that calls
dsymForUUID on a background thread for images as they appear in the
current backt

[lldb] Expand background symbol download (#80890)

LLDB has a setting (symbols.enable-background-lookup) that calls
dsymForUUID on a background thread for images as they appear in the
current backtrace. Originally, the laziness of only looking up symbols
for images in the backtrace only existed to bring the number of
dsymForUUID calls down to a manageable number.

Users have requesting the same functionality but blocking. This gives
them the same user experience as enabling dsymForUUID globally, but
without the massive upfront cost of having to download all the images,
the majority of which they'll likely not need.

This patch renames the setting to have a more generic name
(symbols.auto-download) and changes its values from a boolean to an
enum. Users can now specify "off", "background" and "foreground". The
default remains "off" although I'll probably change that in the near
future.

show more ...

[lldb] Replace deprecated `std::unique_ptr::unique()` to silence a warning with MS-STL. NFC.

MS-STL warns about this with `warning STL4016: std::shared_ptr::unique() is deprecated in C++17`.

Ensure that the executable module is ModuleList[0] (#78360)

We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce

Ensure that the executable module is ModuleList[0] (#78360)

We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce that
in the ModuleList class. As we saw, for instance, in

32dd5b20973bde1ef77fa3b84b9f85788a1a303a

it's not all that hard to get this to be off. This patch ensures that
the first object file of type Executable added to it is moved to the
front of the ModuleList. I also added a test for this.

In the normal course of operation, where the executable is added first,
this only adds a check for whether the first element in the module list
is an executable. If that's true, we just append as normal.

Note, the code in Target::GetExecutableModule doesn't actually agree
that the zeroth element must be the executable, it instead returns the
first Module of type Executable. But I can't tell whether that was a
change in intention or just working around the bug that we don't always
maintain this ordering. But given we've said this in scripting as well
as internally, I think we shouldn't change our minds about this.

show more ...

Add support for inline DWARF source files. (#75880)

LLVM supports DWARF 5 linetable extension to store source files inline
in DWARF. This is particularly useful for compiler-generated source
code.

Add support for inline DWARF source files. (#75880)

LLVM supports DWARF 5 linetable extension to store source files inline
in DWARF. This is particularly useful for compiler-generated source
code. This implementation tries to materialize them as temporary files
lazily, so SBAPI clients don't need to be aware of them.

rdar://110926168

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] Remove LocateSymbolFile (#71301)

This completes the conversion of LocateSymbolFile into a SymbolLocator
plugin. The only remaining function is DownloadSymbolFileAsync which
doesn't really f

[lldb] Remove LocateSymbolFile (#71301)

This completes the conversion of LocateSymbolFile into a SymbolLocator
plugin. The only remaining function is DownloadSymbolFileAsync which
doesn't really fit into the plugin model, and therefore moves into the
SymbolLocator class, while still relying on the plugins to do the
underlying work.

show more ...

[lldb] Convert LocateSymbolFile into a plugin (#71151)

This commit contains the initial scaffolding to convert the
functionality currently implemented in LocateSymbolFile to a plugin
a

[lldb] Convert LocateSymbolFile into a plugin (#71151)

This commit contains the initial scaffolding to convert the
functionality currently implemented in LocateSymbolFile to a plugin
architecture. The plugin approach allows us to easily add new ways to
find symbols and fixes some issues with the current implementation.

For instance, currently we (ab)use the host OS to include support for
querying the DebugSymbols framework on macOS. The plugin approach
retains all the benefits (including the ability to compile this out on
other platforms) while maintaining a higher level of separation with the
platform independent code.

To limit the scope of this patch, I've only converted a single function:
LocateExecutableObjectFile. Future commits will convert the remaining
LocateSymbolFile functions and eventually remove LocateSymbolFile. To
make reviewing easier, that will done as follow-ups.

show more ...

[lldb] Fix duplicate word typos; NFC

Those fixes were taken from https://reviews.llvm.org/D137338

[lldb][NFCI] Remove unneeded ConstString conversions

ConstString can be implicitly converted into a llvm::StringRef. This is
very useful in many places, but it also hides places where we are
creatin

[lldb][NFCI] Remove unneeded ConstString conversions

ConstString can be implicitly converted into a llvm::StringRef. This is
very useful in many places, but it also hides places where we are
creating a ConstString only to use it as a StringRef for the entire
lifespan of the ConstString object.

I locally removed the implicit conversion and found some of the places we
were doing this.

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

show more ...

[lldb] Fix warnings

This patch fixes warnings like:

lldb/source/Core/ModuleList.cpp:1086:3: error: 'scoped_lock' may not
intend to support class template argument deduction
[-Werror,-Wctad-ma

[lldb] Fix warnings

This patch fixes warnings like:

lldb/source/Core/ModuleList.cpp:1086:3: error: 'scoped_lock' may not
intend to support class template argument deduction
[-Werror,-Wctad-maybe-unsupported]

show more ...

[lldb] Implement ModuleList::Swap

[lldb][NFCI] Methods to load scripting resources should take a Stream by reference

These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we alway

[lldb][NFCI] Methods to load scripting resources should take a Stream by reference

These methods all take a `Stream *` to get feedback about what's going
on. By default, it's a nullptr, but we always feed it with a valid
pointer. It would therefore make more sense to have this take a
reference.

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

show more ...

[lldb] Migrate to GetPropertyAtIndexAs for FileSpecList (NFC)

Use the templated GetPropertyAtIndexAs helper for FileSpecList.

[lldb] Eliminate {Get,Set}PropertyAtIndexAsFileSpec (NFC)

This patch is a continuation of 6f8b33f6dfd0 and eliminates the
{Get,Set}PropertyAtIndexAsFileSpec functions.

[lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC)

There's no reason for FileSpecList to live in lldb/Core while FileSpec
lives in lldb/Utility. Move FileSpecList next to FileSpec.

[lldb] Use templates to simplify {Get,Set}PropertyAtIndex (NFC)

Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new propertie

[lldb] Use templates to simplify {Get,Set}PropertyAtIndex (NFC)

Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new properties.
After this patch, SetPropertyAtIndex infers the type from its arguments
and GetPropertyAtIndex required a single template argument for the
return value. As an added benefit, this enables us to remove a bunch of
wrappers from UserSettingsController and OptionValueProperties.

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

show more ...

[lldb] Make exe_ctx an optional argument in OptionValueProperties (NFC)

The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional

[lldb] Make exe_ctx an optional argument in OptionValueProperties (NFC)

The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.

show more ...

[lldb] Remove unused will_modify argument (NFC)

Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the r

[lldb] Remove unused will_modify argument (NFC)

Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.

show more ...

[lldb] Refactor OptionValueProperties to return a std::optional (NFC)

Similar to fdbe7c7faa54, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows th

[lldb] Refactor OptionValueProperties to return a std::optional (NFC)

Similar to fdbe7c7faa54, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows the caller to
handle situations where there's no value, instead of being unable to
distinguish between the absence of a value and the value happening the
match the fail value. When a fail value is required,
std::optional::value_or() provides the same functionality.

show more ...

[lldb][Module][NFC] Add ModuleList::AnyOf

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

[lldb][Module] Document ModuleList::ForEach and assert nullness

Currently all callsites already assume the pointer is non-null.
This patch just asserts this assumption.

This is practically enforced

[lldb][Module] Document ModuleList::ForEach and assert nullness

Currently all callsites already assume the pointer is non-null.
This patch just asserts this assumption.

This is practically enforced by `ModuleList::Append`
which won't add `nullptr`s to `m_modules`.

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

show more ...