[lldb] Fix std::unordered_* synthetic children when typedefs are used. (#123125)

There was a bug in both the GNU and libc++ library synthetic child
providers when a typedef was used in the type of

[lldb] Fix std::unordered_* synthetic children when typedefs are used. (#123125)

There was a bug in both the GNU and libc++ library synthetic child
providers when a typedef was used in the type of the variable. Previous
code was looking at the top level typename to try and determine if
std::unordered_ was a map or set and this failed when typedefs were
being used. This patch fixes both C++ library synthetic child providers
with updated tests.

show more ...

[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] Support new libc++ __compressed_pair layout (#96538)

This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.

This is mostly r

[lldb] Support new libc++ __compressed_pair layout (#96538)

This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.

This is mostly reviewable now. With the new layout we no longer need to
unwrap the `__compressed_pair`. Instead, we just need to look for child
members. E.g., to get to the underlying pointer of `std::unique_ptr` we
no longer do,
```
GetFirstValueOfCXXCompressedPair(GetChildMemberWithName("__ptr_"))

```
but instead do
```
GetChildMemberWithName("__ptr_")
```

We need to be slightly careful because previously the
`__compressed_pair` had a member called `__value_`, whereas now
`__value_` might be a member of the class that used to hold the
`__compressed_pair`. So before unwrapping the pair, we added checks for
`isOldCompressedLayout` (not sure yet whether folding this check into
`GetFirstValueOfCXXCompressedPair` is better).

show more ...

[lldb][DataFormatter] Simplify std::unordered_map::iterator formatter (#97754)

Depends on https://github.com/llvm/llvm-project/pull/97752

This patch changes the way we retrieve the key/value pair

[lldb][DataFormatter] Simplify std::unordered_map::iterator formatter (#97754)

Depends on https://github.com/llvm/llvm-project/pull/97752

This patch changes the way we retrieve the key/value pair in the
`std::unordered_map::iterator` formatter (similar to how we are changing
it for `std::map::iterator` in
https://github.com/llvm/llvm-project/pull/97713, the motivations being
the same).

The old logic was not very easy to follow, and encoded the libc++ layout
in non-obvious ways. But mainly it was also fragile to alignment
miscalculations (https://github.com/llvm/llvm-project/pull/97443); this
would break once the new layout of `std::unordered_map` landed as part
of https://github.com/llvm/llvm-project/issues/93069.

Instead, this patch simply casts the `__hash_iterator` to a
`__node_pointer` (which is what libc++ does too) and uses a
straightforward `GetChildMemberWithName("__value_")` to get to the
key/value we care about.

The `std::unordered_map` already does it this way, so we align the
iterator counterpart to do the same. We can eventually re-use the
core-part of the `std::unordered_map` and `std::unordered_map::iterator`
formatters. But it will be an easier to change to review once both
simplifications landed.

show more ...

[lldb][DataFormatter] Move std::unordered_map::iterator formatter into LibCxxUnorderedMap.cpp (#97752)

Similar to how we moved the `std::map::iterator` formatter in
https://github.com/llvm/llvm-pro

[lldb][DataFormatter] Move std::unordered_map::iterator formatter into LibCxxUnorderedMap.cpp (#97752)

Similar to how we moved the `std::map::iterator` formatter in
https://github.com/llvm/llvm-project/pull/97687, do the same for
`std::unordered_map::iterator`.

Again the `unordered_map` and `unordered_map::iterator` formatters try
to do very similar things: retrieve data out of the map. The iterator
formatter does this in a fragile way (similar to how `std::map` does it,
see https://github.com/llvm/llvm-project/pull/97579). Thus we will be
refactoring the `std::unordered_map::iterator` in upcoming patches.
Having it in `LibCxxUnorderedMap` will allow us to re-use some of the
logic (and we won't have to repeat some of the clarification comments).

show more ...

Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)

Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected

This is an NFC change that does no

Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)

Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected

This is an NFC change that does not yet add any error handling or change
any code to return any errors.

This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501

A follow-up PR will wire up error handling.

show more ...

Revert "Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)"

This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.

Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)

Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected

This is an NFC change that does

Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)

Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected

This is an NFC change that does not yet add any error handling or change
any code to return any errors.

This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501

A follow-up PR will wire up error handling.

show more ...

Change GetChildAtIndex to take a uint32_t

Change the return type of SyntheticFrontend::CalculateNumChildren to int32_t

This way it is consistent with ValueObject and TypeSystem.

[lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return an enum (#80167)

This patch changes the return value of
`SyntheticChildrenFrontend::Update` to a scoped enum that aims to

[lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return an enum (#80167)

This patch changes the return value of
`SyntheticChildrenFrontend::Update` to a scoped enum that aims to
describe what the return value means.

show more ...

[lldb][DataFormatter][NFC] Use GetFirstValueOfLibCXXCompressedPair throughout formatters (#80133)

This avoids duplicating the logic to get the first
element of a libc++ `__compressed_pair`. This wi

[lldb][DataFormatter][NFC] Use GetFirstValueOfLibCXXCompressedPair throughout formatters (#80133)

This avoids duplicating the logic to get the first
element of a libc++ `__compressed_pair`. This will
be useful in supporting upcoming changes to the layout
of `__compressed_pair`.

Drive-by changes:
* Renamed `m_item` to `size_node` for readability;
`m_item` suggests it's a member variable, which it
is not.

show more ...

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[lldb][DataFormatter] unordered_map: account for new libc++ __hash_node layout (#68574)

Since D101206 (`ba79fb2e1ff7130cde02fbbd325f0f96f8a522ca`) the `__hash_node::__value_`
member is wrapped in a

[lldb][DataFormatter] unordered_map: account for new libc++ __hash_node layout (#68574)

Since D101206 (`ba79fb2e1ff7130cde02fbbd325f0f96f8a522ca`) the `__hash_node::__value_`
member is wrapped in an anonymous union. `ValueObject::GetChildMemberWithName` doesn't see
through the union.

This patch accounts for this possible new layout by getting a handle to
the union before doing the by-name `__value_` lookup.

show more ...

Don't allow SBValue::Cast to cast from a smaller type to a larger,
as we don't in general know where the extra data should come from.

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

[lldb] Default can_create to true in GetChildAtIndex (NFC)

Existing callers of `GetChildAtIndex` pass true for can_create. This change
makes true the default value, callers don't have to pass an opa

[lldb] Default can_create to true in GetChildAtIndex (NFC)

Existing callers of `GetChildAtIndex` pass true for can_create. This change
makes true the default value, callers don't have to pass an opaque true.

See also D151966 for the same change to `GetChildMemberWithName`.

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

show more ...

[lldb] Default can_create to true in GetChildMemberWithName (NFC)

It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`.
This change makes `true` the default value

[lldb] Default can_create to true in GetChildMemberWithName (NFC)

It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`.
This change makes `true` the default value, callers don't have to pass an opaque true.

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

show more ...

[lldb] Take StringRef names in GetChildAtNamePath (NFC)

Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef`
values instead of `ConstString`.

Differential Revision: ht

[lldb] Take StringRef names in GetChildAtNamePath (NFC)

Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef`
values instead of `ConstString`.

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

show more ...

[lldb] Take StringRef name in GetChildMemberWithName (NFC)

`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the nee

[lldb] Take StringRef name in GetChildMemberWithName (NFC)

`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the need for callers to construct a
`ConstString`. I don't expect this change to improve performance, only ergonomics.

This is in support of Alex's effort to replace `ConstString` where appropriate.

There are related `ValueObject` functions that can also be changed, if this is accepted.

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

show more ...

[lldb] Don't assume name of libc++ inline namespace in LibCxxUnorderedMap

Follow up to D117383, fixing the assumption that libc++ always uses `__1` as
its inline namespace name.

Reviewed By: ruppre

[lldb] Don't assume name of libc++ inline namespace in LibCxxUnorderedMap

Follow up to D117383, fixing the assumption that libc++ always uses `__1` as
its inline namespace name.

Reviewed By: rupprecht

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

show more ...

[lldb] From unordered_map synthetic provider, return std::pair children

Change the behavior of the libc++ `unordered_map` synthetic provider to present
children as `std::pair` values, just like `std

[lldb] From unordered_map synthetic provider, return std::pair children

Change the behavior of the libc++ `unordered_map` synthetic provider to present
children as `std::pair` values, just like `std::map` does.

The synthetic provider for libc++ `std::unordered_map` has returned children
that expose a level of internal structure (over top of the key/value pair). For
example, given an unordered map initialized with `{{1,2}, {3, 4}}`, the output
is:

```
(std::unordered_map<int, int, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = {
__cc = (first = 3, second = 4)
}
[1] = {
__cc = (first = 1, second = 2)
}
}
```

It's not ideal/necessary to have the numbered children embdedded in the `__cc`
field.

Note: the numbered children have type
`std::__hash_node<std::__hash_value_type<Key, T>, void *>::__node_value_type`,
and the `__cc` fields have type `std::__hash_value_type<Key, T>::value_type`.

Compare this output to `std::map`:

```
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = (first = 1, second = 2)
[1] = (first = 3, second = 4)
```

Where the numbered children have type `std::pair<const Key, T>`.

This changes the behavior of the synthetic provider for `unordered_map` to also
present children as `pairs`, just like `std::map`.

It appears the synthetic provider implementation for `unordered_map` was meant
to provide this behavior, but was maybe incomplete (see
d22a94377f7554a7e9df050f6dfc3ee42384e3fe). It has both an `m_node_type` and an
`m_element_type`, but uses only the former. The latter is exactly the type
needed for the children pairs. With this existing code, it's not much of a
change to make this work.

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

show more ...

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in cl

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

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

show more ...

Make some libstd++ formatters safer

We need to add checks that ensure that some core variables are valid, so
that we avoid printing out garbage data. The worst that could happen is
that an non-initi

Make some libstd++ formatters safer

We need to add checks that ensure that some core variables are valid, so
that we avoid printing out garbage data. The worst that could happen is
that an non-initialized variable is being printed as something with
123123432 children instead of 0.

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

show more ...

[lldb] Move clang-based files out of Symbol

Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSyst

[lldb] Move clang-based files out of Symbol

Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h

This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.

Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik

Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits

Tags: #lldb

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

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