[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] Avoid (unlimited) GetNumChildren calls when printing values (#93946)

For some data formatters, even getting the number of children can be an
expensive operations (e.g., needing to walk a lin

[lldb] Avoid (unlimited) GetNumChildren calls when printing values (#93946)

For some data formatters, even getting the number of children can be an
expensive operations (e.g., needing to walk a linked list to determine
the number of elements). This is then wasted work when we know we will
be printing only small number of them.

This patch replaces the calls to GetNumChildren (at least those on the
"frame var" path) with the calls to the capped version, passing the
value of `max-children-count` setting (plus one)

show more ...

[lldb] FormatManager::GetPossibleMatches assumes all ValueObjects have targets. (#93880)

But one made in a situation where that's impossible might only have an
error, and no symbol context, so that

[lldb] FormatManager::GetPossibleMatches assumes all ValueObjects have targets. (#93880)

But one made in a situation where that's impossible might only have an
error, and no symbol context, so that's not necessarily true. Check for
the target's validity before using it.

Fixes issue #93313

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

[lldb] Refactor GetFormatFromCString to always check for partial matches (NFC) (#81018)

Refactors logic in `ParseInternal` that was previously calling
`GetFormatFromCString` twice, once with `part

[lldb] Refactor GetFormatFromCString to always check for partial matches (NFC) (#81018)

Refactors logic in `ParseInternal` that was previously calling
`GetFormatFromCString` twice, once with `partial_match_ok` set to false,
and the second time set to true.

With this change, lldb formats (ie `%@`, `%S`, etc) are checked first.
If a format is not one of those, then `GetFormatFromCString` is called
once, and now always checks for partial matches.

show more ...

[lldb] Add log indicating which kind of data formatter

The `formatter` logs include a function name, but these functions are mostly templates
and the template type parameter is not printed, which is

[lldb] Add log indicating which kind of data formatter

The `formatter` logs include a function name, but these functions are mostly templates
and the template type parameter is not printed, which is useful context.

This change adds a new log which is printed upon entry of `FormatManager::Get`, which
shows the formatter context as either `format`, `summary`, or `synthetic`.

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

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

Replace deprecated startswith_insensitive with starts_with_insensitive

[lldb] Change formatter helper function parameter list to remove ConstString

All of these functions take a ConstString for the type_name,
but this isn't really needed for two reasons:
1.) This param

[lldb] Change formatter helper function parameter list to remove ConstString

All of these functions take a ConstString for the type_name,
but this isn't really needed for two reasons:
1.) This parameter is always constructed from a static c-string
constant.
2.) They are passed along to to `AddTypeSummary` as a StringRef anyway.

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

show more ...

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The new method
allows users to specify the name of a Python callback function that
takes a `SBType` object and decides whether the type is a match or not.

Here is an overview of the changes performed:

- Add a new `eFormatterMatchCallback` matching type, and logic to handle
it in `TypeMatcher` and `SBTypeNameSpecifier`.

- Extend `FormattersMatchCandidate` instances with a pointer to the
current `ScriptInterpreter` and the `TypeImpl` corresponding to the
candidate type, so we can run registered callbacks and pass the type
to them. All matcher search functions now receive a
`FormattersMatchCandidate` instead of a type name.

- Add some glue code to ScriptInterpreterPython and the SWIG bindings to
allow calling a formatter matching callback. Most of this code is
modeled after the equivalent code for watchpoint callback functions.

- Add an API test for the new callback-based matching feature.

For more context, please check the RFC thread where this feature was
originally discussed:
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11

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

show more ...

[NFCI] More TypeCategoryImpl refactoring.

The main aim of this patch is to delete the remaining instances of code
reaching into the internals of `TypeCategoryImpl`. I made the following
changes:

-

[NFCI] More TypeCategoryImpl refactoring.

The main aim of this patch is to delete the remaining instances of code
reaching into the internals of `TypeCategoryImpl`. I made the following
changes:

- Add some more methods to `TieredFormatterContainer` and
`TypeCategoryImpl` to expose functionality that is implemented in
`FormattersContainer`.

- Add new overloads of `TypeCategoryImpl::AddTypeXXX` to make it easier
to add formatters to categories without reaching into the internal
`FormattersContainer` objects.

- Remove the `GetTypeXXXContainer` and `GetRegexTypeXXXContainer`
accessors from `TypeCategoryImpl` and update all call sites to use the
new methods instead.

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

show more ...

[lldb] Use std::size instead of llvm::array_lengthof

LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpf

[lldb] Use std::size instead of llvm::array_lengthof

LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.

Change call sites to use `std::size` instead.

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

show more ...

Move FormattersMatchCandidate flags to a struct.

This removes some error-prone repetition in
FormatManager::GetPossibleMatches, where the same three boolean flags
are passed in a row multiple times

Move FormattersMatchCandidate flags to a struct.

This removes some error-prone repetition in
FormatManager::GetPossibleMatches, where the same three boolean flags
are passed in a row multiple times as arguments to recursive calls to
GetPossibleMatches.

Instead of:
```
// same flags, but with did_strip_typedef set to true.
GetPossibleMatches(..., did_strip_ptr, did_strip_ref, true);
```
we can now say
```
GetPossibleMatches(..., current_flags.WithStrippedTypedef());
```
which hopefully makes the intent clearer, and more readable in case we
add another flag.

Reviewed by: DavidSpickett, labath

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

show more ...

[lldb] Remove usages of case-insensitive c-string functions

They are not portable (which meant we had a hand-rolled implementation
for windows), and llvm::StringRef provides equivalent functionality.

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

[lldb] Remove summary for signed char *

It conflicts with the summary for BOOL * (aka signed char *). This
partially reverts D112709.

[lldb] Summary provider for char flexible array members

Add a summary provider which can print char[] members at the ends of
structs.

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

[lldb] Fix matchers for char array formatters

They were being applied too narrowly (they didn't cover signed char *,
for instance), and too broadly (they covered SomeTemplate<char[6]>) at
the same t

[lldb] Fix matchers for char array formatters

They were being applied too narrowly (they didn't cover signed char *,
for instance), and too broadly (they covered SomeTemplate<char[6]>) at
the same time.

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

show more ...

[lldb/Formatters] Remove space from vector type string summaries (NFCI)

This patch changes the string summaries for vector types by removing the
space between the type and the bracket, conforming to

[lldb/Formatters] Remove space from vector type string summaries (NFCI)

This patch changes the string summaries for vector types by removing the
space between the type and the bracket, conforming to 277623f4d5a6.

This should also fix TestCompactVectors failure.

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

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

show more ...

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing Ha

Recommit: Compress formatting of array type names (int [4] -> int[4])

Based on post-commit review discussion on
2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c

Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).

show more ...