[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::map formatter (#97579)

Depends on:
* https://github.com/llvm/llvm-project/pull/97544
* https://github.com/llvm/llvm-project/pull/97549
* https://github.com/ll

[lldb][DataFormatter] Simplify std::map formatter (#97579)

Depends on:
* https://github.com/llvm/llvm-project/pull/97544
* https://github.com/llvm/llvm-project/pull/97549
* https://github.com/llvm/llvm-project/pull/97551

This patch tries to simplify the way in which the `std::map` formatter
goes from the root `__tree` pointer to a specific key/value pair.

Previously we would:
1. synthesize a structure that mimicked what `__iter_pointer` looked
like in memory
2. call `GetChildCompilerTypeAtIndex` on it to find the byte offset at
which the pair was located in the synthesized structure
3. finally, use that offset through a call to
`GetSyntheticChildAtOffset` to retrieve the key/value pair

Not only was this logic hard to follow, and encoded the libc++ layout in
non-obvious ways, it was also fragile to alignment miscalculations
(https://github.com/llvm/llvm-project/pull/97443); this would break once
the new layout of std::map landed as part of
https://github.com/https://github.com/llvm/llvm-project/issues/93069.

Instead, this patch simply casts the `__iter_pointer` to the
`__node_pointer` and uses a straightforward
`GetChildMemberWithName("__value_")` to get to the key/value we care
about. This allows us to get rid of some support infrastructure/class
state.

Ideally we would fix the underlying alignment issue, but this unblocks
the libc++ refactor in the interim, while also benefitting the formatter
in terms of readability (in my opinion).

show more ...

[lldb][DataFormatter] Simplify libc++ std::map::iterator formatter (#97713)

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

Similar to https://github.com/llvm/llvm-project/pull/97579,

[lldb][DataFormatter] Simplify libc++ std::map::iterator formatter (#97713)

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

Similar to https://github.com/llvm/llvm-project/pull/97579, this patch
simplifies the way in which we retrieve the key/value pair of a
`std::map` (in this case of the `std::map::iterator`).

We do this for the same reason: not only was the old logic hard to
follow, and encoded the libc++ layout in non-obvious ways, it was also
fragile to alignment miscalculations
(https://github.com/llvm/llvm-project/pull/97443); this would break once
the new layout of std::map landed as part of
https://github.com/llvm/llvm-project/issues/93069.

Instead, this patch simply casts the `__iter_pointer` to the
`__node_pointer` and uses a straightforward
`GetChildMemberWithName("__value_")` to get to the key/value we care
about.

We can eventually re-use the core-part of the `std::map` and
`std::map::iterator` formatters. But it will be an easier to change to
review once both simplifications landed.

show more ...

[lldb][DataFormatter] Remove support for old std::map layout (#97549)

We currently supported the layout from pre-2016 (before the layout
change in
[14caaddd3f08e798dcd9ac0ddfc](https://github.com/

[lldb][DataFormatter] Remove support for old std::map layout (#97549)

We currently supported the layout from pre-2016 (before the layout
change in
[14caaddd3f08e798dcd9ac0ddfc](https://github.com/llvm/llvm-project/commit/14caaddd3f08e798dcd9ac0ddfc)).
We have another upcoming layout change in `__tree` and `map` (as part of
https://github.com/llvm/llvm-project/issues/93069) which will likely
require rewriting parts of this formatter. Removing the support for the
pre-2016 layout will make those changes more straightforward to
review/maintain.

Being backward compatible would be great but we have no tests that
actually verify that the old layout still works (and our oldest matrix
bot tests clang-15). If anyone feels strongly about keeping this layout,
we could possibly factor out that logic and keep it around.

show more ...

[lldb][DataFormatter][NFC] Move std::map iterator formatter into LibCxxMap.cpp (#97687)

The two formatters follow very similar techniques to retrieve data out
of the map. We're changing this for `s

[lldb][DataFormatter][NFC] Move std::map iterator formatter into LibCxxMap.cpp (#97687)

The two formatters follow very similar techniques to retrieve data out
of the map. We're changing this for `std::map` in
https://github.com/llvm/llvm-project/pull/97579 and plan to change it in
the same way for the iterator formatter. Having them in the same place
will allow us to re-use some of the logic (and we won't have to repeat
some of the clarification comments).

show more ...

[lldb][DataFormatter][NFC] Factor out MapIterator logic into separate helper (#97544)

This patch factors all the logic for advancing the `MapIterator` out of
`GetChildAtIndex`. This, in my opinion,

[lldb][DataFormatter][NFC] Factor out MapIterator logic into separate helper (#97544)

This patch factors all the logic for advancing the `MapIterator` out of
`GetChildAtIndex`. This, in my opinion, helps readability, and will be
useful for upcoming cleanups in this area.

While here, some drive-by changes:
* added a couple of clarification comments
* fixed a variable name typo
* turned the `return lldb::ValueObjectSP()` into `return nullptr`
* added an assertion to make sure we keep the iterator cache in a valid
state

show more ...

[lldb][DataFormatter][NFC] std::map: minor restructuring in GetChildAtIndex to use early-return

[lldb][DataFormatter][NFC] std::map: Add comments and other minor cleanups

[lldb][DataFormatter][NFC] Remove redundant variables in std::map formatter

Redundant since:
```
commit be3be28b5d5c97de1c26bf069e0b82043d938f30
Author: Enrico Granata <egranata@apple.com>
Date: M

[lldb][DataFormatter][NFC] Remove redundant variables in std::map formatter

Redundant since:
```
commit be3be28b5d5c97de1c26bf069e0b82043d938f30
Author: Enrico Granata <egranata@apple.com>
Date: Mon Oct 3 23:33:00 2016 +0000

Changes to the std::multimap formatter to make it work against trunk libc++

Fixes rdar://28237486

llvm-svn: 283160
```

show more ...

Change GetChildCompilerTypeAtIndex to return Expected (NFC) (#92979)

This change is a general improvement of the internal API. My motivation
is to use this in the Swift typesystem plugin.

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][NFCI] TypeSystemClang::CreateStructForIdentifier should take a StringRef

This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string

[lldb][NFCI] TypeSystemClang::CreateStructForIdentifier should take a StringRef

This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.

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

show more ...

[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] Fixes summary formatter for libc++ map allowing modification of contained value

Reviewed By: clayborg

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

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