Commit Graph

424 Commits

Author SHA1 Message Date
Jan Kratochvil 14f443030c [nfc] [lldb] Prevent needless copies of DataExtractor
lldb_private::DataExtractor contains DataBufferSP m_data_sp which is
relatively expensive to copy (due to multi-threading locking).

llvm::DataExtractor does not have this problem as it uses StringRef
instead.

The copy constructor is explicit as otherwise it is easy to make
unintended modification of a local copy instead of a caller's instance
(D107470 but that is llvm::DataExtractor).

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D107485
2021-08-04 20:35:53 +02:00
Jonas Devlieghere fd2433e139 [lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
2021-07-02 11:31:16 -07:00
Jonas Devlieghere 9494c510af [lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
2021-06-09 09:43:13 -07:00
Raphael Isemann 76e47d4887 [lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
2021-05-26 12:46:12 +02:00
Raphael Isemann 03310c1e95 [lldb][NFC] Give CompilerType's IsArrayType/IsVectorType/IsBlockPointerType out-parameters default values
We already do this for most functions that have out-parameters, so let's do
the same here and avoid all the `nullptr, nullptr, nullptr` in every call.
2021-02-23 11:15:31 +01:00
Raphael Isemann d77e3c6aec [lldb][NFC] Don't inherit from UserID in ValueObject
ValueObject inherits from UserID which is just a bad idea:

* The inheritance gives ValueObject some member functions that are at best
  misleading (such as `Clear()` which doesn't clear any value beside `id`).

* It allows passing ValueObject to the overloaded operators for UserID (such as
  `==` or `<<` which won't actually compare or print anything in the ValueObject).

* It exposes the `SetID` and `Clear` which both allow users to change the
  internal id value.

Similar to D91699 which did the same for Process

Reviewed By: #lldb, JDevlieghere

Differential Revision: https://reviews.llvm.org/D97205
2021-02-23 10:15:42 +01:00
Adrian Prantl 057efa9916 Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537
2021-02-12 16:12:31 -08:00
Raphael Isemann 839e845277 [lldb] Remove assumption from Clang-based data formatters that their types are in the scratch AST
Several data formatters assume their types are in the Target's scratch AST and
build new types from that scratch AST instance. However, types from different
ASTs shouldn't be mixed, so this (unchecked) assumption may lead to problems if
we ever have more than one scratch AST or someone somehow invokes data
formatters on a type that are not in the scratch AST.

Instead we can use in all the formatters just the TypeSystem of the type we're
formatting. That's much simpler and avoids all the headache of finding the right
TypeSystem that matches the one of the formatted type.

Right now LLDB only has one scratch TypeSystemClang instance and we format only
types that are in the scratch AST, so this doesn't change anything in the
current way LLDB works. The intention here is to allow follow up refactorings
that introduce multiple scratch ASTs with the same Target.

Differential Revision: https://reviews.llvm.org/D92757
2020-12-10 17:35:03 +01:00
Jonas Devlieghere 406ad18748 [lldb/DataFormatters] Display null C++ pointers as nullptr
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.

Differential revision: https://reviews.llvm.org/D77153
2020-11-12 15:24:06 -08:00
Raphael Isemann 77ae06b8c6 [lldb][NFC] Remove FormatMap
Summary:

FormattersContainer.h has two containers: FormatMap and FormattersContainer
itself. FormatMap is essentially just a SetVector with a listener interface that
is aspiring to be thread-safe as most of its functions lock its member mutex.

FormattersContainer is for the most part just calling the matching functions of
internal FormatMap instance and essentially acts as a wrapper class with some
minor formatter search functionality on top. The only difference is that the
FormattersContainer's public `Get` function is actually searching formatters in
the list of formatters (and for example doing regex-matching) while FormatMap's
`Get` function is just looking up a a format by the type matcher string.

This patch deletes `FormatMap` by just renaming it to `FormattersContainer` and
pulling in the two `Get` functions from the original `FormattersContainer`
class.

The only other user of `FormatMap` was the `NamedSummariesMap` in the
`FormatManager` which I migrated by just making it also a `FormattersContainer`
and replaced the only call to the `Get` function (which now has new semantics)
with `GetExact` (which is FormattersContainer's function that has the semantics
of FormatMap's `Get`). As `NamedSummariesMap` only stores non-regex-based
formatters, both `Get` and `GetExact` would have worked, so this was mostly to
clarify that this is supposed to be NFC.

I also added the missing mutex lock in the `GetCount` function which was
previously missing in the `FormatMap` implementation. Technically not "NFC" but
I anyway had to change the function...

Reviewers: labath, mib

Reviewed By: labath

Subscribers: abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D84296
2020-07-23 18:34:59 +02:00
Raphael Isemann 4d489e9f91 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
2020-07-23 18:17:42 +02:00
Eric Christopher 3a75466f41 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 074b121642.
2020-07-23 00:47:05 -07:00
Adrian Prantl 02f5837363 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
2020-07-22 08:56:29 -07:00
Raphael Isemann 074b121642 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
2020-07-22 09:32:28 +02:00
Raphael Isemann e031eda08d Revert "[lldb] Unify type name matching in FormattersContainer"
This reverts commit 5b0de5756c.

Apparently that caused some test to get stuck on Linuxx. Reverting for now.
2020-07-21 19:03:33 +02:00
Raphael Isemann 5b0de5756c [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
2020-07-21 18:44:50 +02:00
Raphael Isemann 5c15426d7c [lldb] Remove FormattersContainer's name member
Summary:

FormattersContainer currently has an unused `m_name` member. Usually LLDB allows
giving objects names, but for the FormattersContainer it seems excessive. There
are only 4 FormattersContainer variables in LLDB and they are not usually passed
around, so one can always just go up a few frames when debugging to find out
which FormattersContainer you're dealing with.

Reviewers: mib, davide

Reviewed By: mib

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D84154
2020-07-21 13:54:38 +02:00
Jonas Devlieghere 58e34ede5b [lldb] Small improvements in ValueObjectPrinter::PrintDecl (NFC)
Remove unused argument, simply code and reformat.
2020-06-12 21:05:05 -07:00
Vedant Kumar 4699a7e230 [lldb/StringPrinter] Support strings with invalid utf8 sub-sequences
Support printing strings which contain invalid utf8 sub-sequences, e.g.
strings like "hello world \xfe", instead of bailing out with "Summary
Unavailable".

I took the opportunity here to delete some hand-rolled utf8 -> utf32
conversion code and replace it with calls into llvm's Support library.

rdar://61554346
2020-06-03 12:24:23 -07:00
Vedant Kumar 7822b8a817 [lldb/StringPrinter] Convert DecodedCharBuffer to a class, NFC
The m_size and m_data members of DecodedCharBuffer are meant to be
private.
2020-06-03 12:24:23 -07:00
Vedant Kumar a37caebc2d [lldb/DataFormatters] Delete GetStringPrinterEscapingHelper
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".

To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.

IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.

A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.

rdar://61419673

Reviewers: JDevlieghere, davide

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77843
2020-05-04 14:06:55 -07:00
Pavel Labath 9cd9f3f1b8 [lldb] Fix gcc warnings in TypeCategory.cpp
The cleanup in 3e3701f8a0 left these variable unused.
2020-04-20 16:12:51 +02:00
Raphael Isemann 3e3701f8a0 [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
2020-04-15 09:47:15 +02:00
Raphael Isemann 6b6a779ca8 [lldb][NFC] Always update m_cache_{hits/misses} in FormatCache
Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:

```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```

This just always increments those two counters independent of build mode.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D76687
2020-03-24 20:16:43 +01:00
shafik a567d6809e [DataFormatters] Add formatter for libc++ std::unique_ptr
This adds a formatter for libc++ std::unique_ptr.

I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.

Differential Revision: https://reviews.llvm.org/D76476
2020-03-23 11:48:20 -07:00
Raphael Isemann 7b2442584e Reland [lldb] Fix string summary of an empty NSPathStore2
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix
the Debian tests).

Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).

It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.

This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).

Reviewers: aprantl, JDevlieghere, shafik

Reviewed By: aprantl

Subscribers: christof, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 18:50:26 +01:00
Raphael Isemann 718d94187d Revert "[lldb] Fix string summary of an empty NSPathStore2"
This reverts commit 939ca455e7.

This failed on the debian bot for some reason:
  File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
    "s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
2020-03-19 13:08:39 +01:00
Raphael Isemann 939ca455e7 [lldb] Fix string summary of an empty NSPathStore2
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).

It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.

This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).

Reviewers: aprantl, JDevlieghere, shafik

Reviewed By: aprantl

Subscribers: christof, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 12:20:35 +01:00
Raphael Isemann 785df61680 [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
2020-02-19 10:30:11 +01:00
Vedant Kumar 7aabad1312 [lldb/StringPrinter] Avoid reading garbage in uninitialized strings
This patch fixes a few related out-of-bounds read bugs in the
string data formatters. These issues have to do with mishandling of un-
initialized strings. These manifest as ASan exceptions when debugging a
clang binary.

The first issue was that the std::string formatter treated strings in
"short mode" with length greater than the size of the inline buffer as
valid.

The second issue was that the StringPrinter facility did not check that
a full utf8 codepoint sequence can be read from the buffer (i.e. there
are some missing range checks). I took the opportunity here to delete
some untested code that was meant to deal with invalid input and replace
it with fail-on-invalid logic ([1][2][3]). This means we'll give up on
formatting an invalid string instead of guessing our way through it.

The third issue is that StringPrinter did not check that a utf8 sequence
could actually be fully read from the string payload. This one is especially
tricky as we may overflow the buffer pointer while reading the sequence.

I also noticed that the std::string formatter would spew the raw version of
the underlying ValueObject when garbage is detected. I've changed this to
just print "Summary Unavailable" instead, as we do elsewhere.

I've added regression tests for these issues to
test/functionalities/data-formatter/data-formatter-stl/libcxx/string.

[1]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L136
[2]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L163
[3]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L357

rdar://59080026

Differential Revision: https://reviews.llvm.org/D73860
2020-02-12 11:24:03 -08:00
Raphael Isemann 30ce956aec [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.
2020-02-12 09:49:39 +01:00
Martin Storsjö 5bbaf54358 [LLDB] Fix compilation with GCC 5
Differential Revision: https://reviews.llvm.org/D74084
2020-02-06 10:16:32 +02:00
Vedant Kumar 63e6508221 [lldb/StringPrinter] Simplify StringPrinterBufferPointer, NFC
Remove its template arguments and delete its copy/assign methods.
2020-02-03 15:57:33 -08:00
Alex Langford 3014efe071 [lldb] Remove unused parameter from ValueObject::GetExpressionPath
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
2020-02-03 10:50:38 -08:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Raphael Isemann 808142876c [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
2020-01-24 08:52:55 +01:00
Jaroslav Sevcik 902974277d 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
2020-01-10 11:45:24 +01:00
Vedant Kumar 46d970cc43 TypeCategory: Initialize m_enabled to false
The initialization was accidentally lost in https://reviews.llvm.org/D71310, causing a ubsan failure:

/Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35: runtime error: load of value 190, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35 in

http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake-sanitized/621/consoleText
2019-12-12 11:39:41 -08:00
Adrian Prantl ee64dfd953 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
2019-12-11 09:27:12 -08:00
Adrian Prantl 2fb07b90dc Remove unsound caching in LanguageCategory
Analogous to https://reviews.llvm.org/D71233 it is not safe to cache
something that depends on the actual ValueObject in a cache then keys
only off the type name.

Differential Revision: https://reviews.llvm.org/D71297
2019-12-10 16:11:10 -08:00
Adrian Prantl b3801de7c5 Replace redundant code in LanguageCategory with templates (NFC)
Differential Revision: https://reviews.llvm.org/D71296
2019-12-10 16:11:10 -08:00
Adrian Prantl 70e3d0ea55 [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
2019-12-10 15:57:53 -08:00
Adrian Prantl 62a6d97704 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
2019-12-10 15:53:40 -08:00
Davide Italiano f387b99745 [DataFormatters] Change the Get() method to take a LanguageType.
Suggested by Adrian.
2019-12-10 15:21:24 -08:00
Davide Italiano bbcdcea4bf [TypeCategory] IsApplicable gets a LanguageType, not a ValueObject.
Reviewers: aprantl, teemperor

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71305
2019-12-10 14:59:34 -08:00
Adrian Prantl 7034794b31 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
2019-12-10 10:27:16 -08:00
Davide Italiano bc69dd2cfa [FormatManager] GetCandidateLanguages shouldn't know about ValueObject.
Reviewers: jingham, teemperor, JDevlieghere, aprantl

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71236
2019-12-09 17:16:20 -08:00
Davide Italiano 295db41ce2 [FormatManager] Provide a single entrypoint for GetCandidateLanguages(). 2019-12-09 14:49:08 -08:00
Davide Italiano 2bb19f93f6 [TypeCategory] HasLanguage() is now unused. 2019-12-03 15:45:23 -08:00
Davide Italiano 89618a7ce1 [DataVisualization] Simplify. NFCI. 2019-12-03 15:03:25 -08:00