[lldb] Make char[N] formatters respect the end of the array (PR44649)

I believe this is a more natural behavior, and it also matches what gdb
does.

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

[lldb] Make char[N] formatters respect the end of the array (PR44649)

I believe this is a more natural behavior, and it also matches what gdb
does.

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

show more ...

Reland [lldb] Unify type name matching in FormattersContainer II

This was originally reverted because the m_valid member in TypeMatcher was
unused in builds with disabled asserts. Now the member is

Reland [lldb] Unify type name matching in FormattersContainer II

This was originally reverted because the m_valid member in TypeMatcher was
unused in builds with disabled asserts. Now the member is gone and the default
constructor is deleted (thanks Eric for the idea!).

Summary:

FormattersContainer stores LLDB's formatters. It's implemented as a templated
map-like data structures that supports any kind of value type and only allows
ConstString and RegularExpression as the key types. The keys are used for
matching type names (e.g., the ConstString key `std::vector` matches the type
with the same name while RegularExpression keys match any type where the
RegularExpression instance matches).

The fact that a single FormattersContainer can only match either by string
comparison or regex matching (depending on the KeyType) causes us to always have
two FormatterContainer instances in all the formatting code. This also leads to
us having every type name matching logic in LLDB twice. For example,
TypeCategory has to implement every method twice (one string matching one, one
regex matching one).

This patch changes FormattersContainer to instead have a single `TypeMatcher`
key that wraps the logic for string-based and regex-based type matching and is
now the only possible KeyType for the FormattersContainer. This means that a
single FormattersContainer can now match types with both regex and string
comparison.

To summarize the changes in this patch:
* Remove all the `*_Impl` methods from `FormattersContainer`
* Instead call the FormatMap functions from `FormattersContainer` with a
`TypeMatcher` type that does the respective matching.
* Replace `ConstString` with `TypeMatcher` in the few places that directly
interact with `FormattersContainer`.

I'm working on some follow up patches that I split up because they deserve their
own review:

* Unify FormatMap and FormattersContainer (they are nearly identical now).
* Delete the duplicated half of all the type matching code that can now use one
interface.
* Propagate TypeMatcher through all the formatter code interfaces instead of
always offering two functions for everything.

There is one ugly design part that I couldn't get rid of yet and that is that we
have to support getting back the string used to construct a `TypeMatcher` later
on. The reason for this is that LLDB only supports referencing existing type
matchers by just typing their respective input string again (without even
supplying if it's a regex or not).

Reviewers: davide, mib

Reviewed By: mib

Subscribers: mgorny, JDevlieghere

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

show more ...

Temporarily Revert "Reland [lldb] Unify type name matching in FormattersContainer"
as it breaks bots with due to m_valid being an unused class member
except in assert builds.

This reverts commit 074

Temporarily Revert "Reland [lldb] Unify type name matching in FormattersContainer"
as it breaks bots with due to m_valid being an unused class member
except in assert builds.

This reverts commit 074b121642b286afb16adeebda5ec8236f7b8ea9.

show more ...

Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)

This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call

Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)

This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.

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

show more ...

Reland [lldb] Unify type name matching in FormattersContainer

This was originally reverted because the Linux bots were red after this landed,
but it seems that was actually caused by a different com

Reland [lldb] Unify type name matching in FormattersContainer

This was originally reverted because the Linux bots were red after this landed,
but it seems that was actually caused by a different commit. I double checked
that this works on Linux, so let's reland this on Linux.

Summary:

FormattersContainer stores LLDB's formatters. It's implemented as a templated
map-like data structures that supports any kind of value type and only allows
ConstString and RegularExpression as the key types. The keys are used for
matching type names (e.g., the ConstString key `std::vector` matches the type
with the same name while RegularExpression keys match any type where the
RegularExpression instance matches).

The fact that a single FormattersContainer can only match either by string
comparison or regex matching (depending on the KeyType) causes us to always have
two FormatterContainer instances in all the formatting code. This also leads to
us having every type name matching logic in LLDB twice. For example,
TypeCategory has to implement every method twice (one string matching one, one
regex matching one).

This patch changes FormattersContainer to instead have a single `TypeMatcher`
key that wraps the logic for string-based and regex-based type matching and is
now the only possible KeyType for the FormattersContainer. This means that a
single FormattersContainer can now match types with both regex and string
comparison.

To summarize the changes in this patch:
* Remove all the `*_Impl` methods from `FormattersContainer`
* Instead call the FormatMap functions from `FormattersContainer` with a
`TypeMatcher` type that does the respective matching.
* Replace `ConstString` with `TypeMatcher` in the few places that directly
interact with `FormattersContainer`.

I'm working on some follow up patches that I split up because they deserve their
own review:

* Unify FormatMap and FormattersContainer (they are nearly identical now).
* Delete the duplicated half of all the type matching code that can now use one
interface.
* Propagate TypeMatcher through all the formatter code interfaces instead of
always offering two functions for everything.

There is one ugly design part that I couldn't get rid of yet and that is that we
have to support getting back the string used to construct a `TypeMatcher` later
on. The reason for this is that LLDB only supports referencing existing type
matchers by just typing their respective input string again (without even
supplying if it's a regex or not).

Reviewers: davide, mib

Reviewed By: mib

Subscribers: mgorny, JDevlieghere

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

show more ...

Revert "[lldb] Unify type name matching in FormattersContainer"

This reverts commit 5b0de5756ccc7a540926e4eeaa3b398539d88cd8.

Apparently that caused some test to get stuck on Linuxx. Reverting for

Revert "[lldb] Unify type name matching in FormattersContainer"

This reverts commit 5b0de5756ccc7a540926e4eeaa3b398539d88cd8.

Apparently that caused some test to get stuck on Linuxx. Reverting for now.

show more ...

[lldb] Unify type name matching in FormattersContainer

Summary:

FormattersContainer stores LLDB's formatters. It's implemented as a templated
map-like data structures that supports any kind of valu

[lldb] Unify type name matching in FormattersContainer

Summary:

FormattersContainer stores LLDB's formatters. It's implemented as a templated
map-like data structures that supports any kind of value type and only allows
ConstString and RegularExpression as the key types. The keys are used for
matching type names (e.g., the ConstString key `std::vector` matches the type
with the same name while RegularExpression keys match any type where the
RegularExpression instance matches).

The fact that a single FormattersContainer can only match either by string
comparison or regex matching (depending on the KeyType) causes us to always have
two FormatterContainer instances in all the formatting code. This also leads to
us having every type name matching logic in LLDB twice. For example,
TypeCategory has to implement every method twice (one string matching one, one
regex matching one).

This patch changes FormattersContainer to instead have a single `TypeMatcher`
key that wraps the logic for string-based and regex-based type matching and is
now the only possible KeyType for the FormattersContainer. This means that a
single FormattersContainer can now match types with both regex and string
comparison.

To summarize the changes in this patch:
* Remove all the `*_Impl` methods from `FormattersContainer`
* Instead call the FormatMap functions from `FormattersContainer` with a
`TypeMatcher` type that does the respective matching.
* Replace `ConstString` with `TypeMatcher` in the few places that directly
interact with `FormattersContainer`.

I'm working on some follow up patches that I split up because they deserve their
own review:

* Unify FormatMap and FormattersContainer (they are nearly identical now).
* Delete the duplicated half of all the type matching code that can now use one
interface.
* Propagate TypeMatcher through all the formatter code interfaces instead of
always offering two functions for everything.

There is one ugly design part that I couldn't get rid of yet and that is that we
have to support getting back the string used to construct a `TypeMatcher` later
on. The reason for this is that LLDB only supports referencing existing type
matchers by just typing their respective input string again (without even
supplying if it's a regex or not).

Reviewers: davide, mib

Reviewed By: mib

Subscribers: mgorny, JDevlieghere

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

show more ...

[lldb][NFC] Remove FormatterChoiceCriterion

Summary:
The formatters code has a lot of 'reason' or 'why' values that we keep or-ing FormatterChoiceCriterion
enum values into. These values are only re

[lldb][NFC] Remove FormatterChoiceCriterion

Summary:
The formatters code has a lot of 'reason' or 'why' values that we keep or-ing FormatterChoiceCriterion
enum values into. These values are only read by a single log statement and don't have any functional
purpose. It also seems the implementation is not finished (for example, display names and type
names don't have any dedicated enum values). Also everything is of course not tested or documented.

Let's just remove all of this.

Reviewers: labath, JDevlieghere, jingham, davide, vsk

Reviewed By: labath, vsk

Subscribers: JDevlieghere

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

show more ...

[lldb] Let TypeSystemClang::GetDisplayTypeName remove anonymous and inline namespaces.

Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous n

[lldb] Let TypeSystemClang::GetDisplayTypeName remove anonymous and inline namespaces.

Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):

```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```

This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:

```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```

As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.

Note that this doesn't touch the `GetTypeName` class that for example the data formatters use, so this patch
is only changes the way we display types to the user. The full type name can also still be found when passing
'-R' to see the raw output of a variable in case someone is somehow interested in that.

Partly fixes rdar://problem/59292534

Reviewers: shafik, jingham

Reviewed By: shafik

Subscribers: christof, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType

Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the

[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType

Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.

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

Data formatters: Look through array element typedefs

Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.

The string formatter currently

Data formatters: Look through array element typedefs

Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.

The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.

Reviewers: teemperor, clayborg

Reviewed By: teemperor, clayborg

Subscribers: clayborg, lldb-commits

Tags: #lldb

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

show more ...

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch remove

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.

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

show more ...

[FormatManager] Move Language lookup into the obviously non-cached part (NFC)

This refactoring makes the lookup caching easier to reason about. This
has no observable effect although it does slightl

[FormatManager] Move Language lookup into the obviously non-cached part (NFC)

This refactoring makes the lookup caching easier to reason about. This
has no observable effect although it does slightly change what is
being cached.

- Before this patch a negative lookup in the LanguageCategory would be
cached, but a positive wouldn't.

- After this patch LanguageCategory lookups aren't cached by
FormatManager, period. (LanguageCategory has its own FormatCache for this!)

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

show more ...

Do not cache hardcoded formats in FormatManager

The cache in FormatCache uses only a type name as key. The hardcoded
formats, synthetic children, etc inspect an entire ValueObject to
determine their

Do not cache hardcoded formats in FormatManager

The cache in FormatCache uses only a type name as key. The hardcoded
formats, synthetic children, etc inspect an entire ValueObject to
determine their eligibility, which isn't modelled in the cache. This
leads to bugs such as the one in this patch (where two similarly named
types in different files have different hardcoded summary
providers). The problem is exaggerated in the Swift language plugin
due to the language's dynamic nature.

rdar://problem/57756763

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

show more ...

Replace redundant code in FormatManager and FormatCache with templates (NFC)

This is a preparatory patch for an upcoming bugfix.

FormatManager and friends have four identical implementations of man

Replace redundant code in FormatManager and FormatCache with templates (NFC)

This is a preparatory patch for an upcoming bugfix.

FormatManager and friends have four identical implementations of many
accessor functions to deal with the four types of shared pointers in
the FormatCache. This patch replaces these implementations with
templates. While this patch drastically reduces the amount of source
code and its maintainablity, it doesn't actually improve code
size. I'd argue, this is still an improvement.

rdar://problem/57756763

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

show more ...

[FormatManager] GetCandidateLanguages shouldn't know about ValueObject.

Reviewers: jingham, teemperor, JDevlieghere, aprantl

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://r

[FormatManager] GetCandidateLanguages shouldn't know about ValueObject.

Reviewers: jingham, teemperor, JDevlieghere, aprantl

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[FormatManager] Provide a single entrypoint for GetCandidateLanguages().

Code cleanup: Change FormattersContainer::KeyType from SP to rvalue

There is now std::shared_ptr passed around which is expensive for manycore
CPUs. Most of the times (except for 3 cases) it is now

Code cleanup: Change FormattersContainer::KeyType from SP to rvalue

There is now std::shared_ptr passed around which is expensive for manycore
CPUs. Most of the times (except for 3 cases) it is now just std::moved with no
CPU locks needed. It also makes it possible to sort the keys (which is now not
needed much after D66398).

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

llvm-svn: 370863

show more ...

[FormatManage] Fix the format info order

The format info entries need to match the order of the enum entries.
This should fix the two failing data-formatter tests.

llvm-svn: 369617

[FormatManager] Add static_assert to keep formats in sync.

This adds a static assert that ensures that there's a format info entry
for every format enum value. This should prevent others from making

[FormatManager] Add static_assert to keep formats in sync.

This adds a static assert that ensures that there's a format info entry
for every format enum value. This should prevent others from making the
same mistake I made and Jason kindly fixed in r369611. (Thanks!)

llvm-svn: 369614

show more ...

The g_format_infos table needs to be updated in concert with the
enum Format entries; else we can crash in a place like
FormatManager::GetFormatAsCString(). We should add bounds checks
to prevent t

The g_format_infos table needs to be updated in concert with the
enum Format entries; else we can crash in a place like
FormatManager::GetFormatAsCString(). We should add bounds checks
to prevent this more reliably, but for tonight I'm just adding this
entry to keep an address-sanitizer test run working.

llvm-svn: 369611

show more ...

Revert "[CompilerType] Simplify the interface a bit more.."

There's actually a test downstream that fails with this.
I think we can still get rid of it, but I need to do some work
there first.

llvm

Revert "[CompilerType] Simplify the interface a bit more.."

There's actually a test downstream that fails with this.
I think we can still get rid of it, but I need to do some work
there first.

llvm-svn: 367963

show more ...

[CompilerType] Simplify the interface a bit more..

Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without d

[CompilerType] Simplify the interface a bit more..

Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without dynamic counterpart] don't carry a lot
of value. Since then, the formatters and dynamic type resolution
has been rewritten, and we employ different solutions. This function
is unused here too, so let's get read of it.

<rdar://problem/36377967>

Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 367957

show more ...

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

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

llvm-svn: 366936

show more ...