- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality
Patch by Shafik Yaghmour!
Differential Revision: https://reviews.llvm.org/D50864
llvm-svn: 340543
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
Summary:
Removing FastDemangle will greatly reduce maintenance efforts. This patch replaces the last point of use in LLDB. Semantics should be kept intact.
Once this is agreed upon, we can:
* Remove the FastDemangle sources
* Add more features e.g. substitutions in template parameters, considering all variations, etc.
Depends on LLVM patch https://reviews.llvm.org/D50586
Reviewers: erik.pilkington, friss, jingham, JDevlieghere
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D50587
llvm-svn: 339583
Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANSI color escape sequences.
So far we have only one highlighter which is based on Clang and is responsible for all
languages that are supported by Clang. It essentially just runs the raw lexer over the input
and then surrounds the specific tokens with the configured escape sequences.
Reviewers: zturner, davide
Reviewed By: davide
Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D49334
llvm-svn: 338662
This broke a linux bot which doesn't support -std=c++17. The solution
is to add a decorator to skip these tests on machines with older compilers.
llvm-svn: 338162
This should have all the correct files now.
<rdar://problem/41471112>
Patch by Shafik Yaghmour.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 338156
The synthetic child providers for these classes had a type expression that matched
pointers & references to the type, but the Front End only worked on the actual object.
I fixed this by adding a way for the Synthetic Child FrontEnd provider to request dereference,
and then had these formatters use that mode.
<rdar://problem/40849836>
Differential Revision: https://reviews.llvm.org/D49279
llvm-svn: 337035
Summary: Check case when _M_t child member is not present.
Reviewers: labath, tberghammer
Reviewed By: labath, tberghammer
Differential Revision: https://reviews.llvm.org/D47932
Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com>.
llvm-svn: 334411
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Now incorrect type argument that looks like T<A><B> doesn't
cause an assert, but just a parsing error.
Bug: 36224
Differential Revision: https://reviews.llvm.org/D42939
llvm-svn: 324380
Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.
Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40615
llvm-svn: 319414
Summary:
Despite it's name, GetTemplateArgument was only really working for Type
template arguments. This adds the ability to retrieve integral arguments
as well (which I've needed for the std::bitset data formatter).
I've done this by splitting the function into three pieces. The idea is
that one first calls GetTemplateArgumentKind (first function) to
determine the what kind of a parameter this is. Based on that, one can
then use specialized functions to retrieve the correct value. Currently,
I only implement two of these: GetTypeTemplateArgument and
GetIntegralTemplateArgument.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39844
llvm-svn: 318040
Summary:
A couple of members of these data structures have been renamed in recent
months. This makes sure they still work with the latest libc++ version.
Reviewers: jingham, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39602
llvm-svn: 317624
Summary:
std::queue is just a fancy wrapper around another container, so all we
need to do is to delegate to the it.
Reviewers: jingham, EricWF
Subscribers: srhines, mgorny, lldb-commits, eugene
Differential Revision: https://reviews.llvm.org/D35666
llvm-svn: 317099
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Reviewers: jingham, EricWF
Subscribers: srhines, eugene, lldb-commits
Differential Revision: https://reviews.llvm.org/D35556
llvm-svn: 316992
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.
Reviewers: #lldb, zturner
Reviewed By: zturner
Subscribers: zturner, tberghammer, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D32503
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301903
Summary:
LLVM r300140 changed the layout and field names of __compressed_pair, which
broke LLDB's std::vector, std::map and std::unsorted_map formatters.
This patch attempts to fix these formatters by having them interogate the
__compressed_pair values to determine whether they're pre- or post-r300140
variants, then access them accordingly.
Reviewers: jingham, EricWF
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D32554
llvm-svn: 301493
ValueObject methods.
Using ArrayRef allows us to remove some overloads, work with more array-like
types, and avoid some std::vector temporaries.
https://reviews.llvm.org/D32518
llvm-svn: 301441
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Previous version of this change (D31451) was rolled back due to an issue
with Objective-C selectors being incorrectly recognized as a C++ identifier.
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299721
This caused a failure in the test case:
functionalities/breakpoint/objc/TestObjCBreakpoints.py
When we are parsing up names we stick interesting parts of the names
in various buckets, one of which is the ObjC selector bucket. The new
C++ name parser must be interfering with this process somehow.
<rdar://problem/31439305>
llvm-svn: 299489
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299374
Summary:
Calling ValueObject::SetName from a sythetic child provider would change
the underying value object used for the non-synthetic child as well what
is clearly unintentional.
Reviewers: jingham, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31371
llvm-svn: 299259
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
Summary:
Displaying the object pointed by the unique_ptr can cause an infinite
recursion when we have a pointer loop so this change stops that
behavior. Additionally it makes the unique_ptr act more like a class
containing a pointer (what is the underlying truth) instead of some
"magic" class.
Reviewers: labath, jingham
Differential Revision: https://reviews.llvm.org/D31366
llvm-svn: 299249
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored
to properly substitute primitive types using a hook in the itanium demangler,
and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement
primitive type parameter as before but parses it using the FastDemangler, which
has been modified to be able to notify clients of parse events (primitive types
at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so
that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223
Subscribers: lldb-commits
llvm-svn: 290117
Summary:
This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This
is a preparatory step to remove our custom android toolchain file and rely on
the standard android NDK one instead, which does not provide this define.
Instead I rely, on __ANDROID__, which is set by the compiler.
I haven't yet removed the cmake variable with the same name, as we will need to
do something completely different there -- NDK toolchain defines
CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux.
Reviewers: tberghammer, zturner
Subscribers: danalbert, srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27305
llvm-svn: 288494
The scanning algorithm had a few little subtleties that I
overlooked, but this patch should fix everything.
I still haven't changed the function to take a StringRef since
that has some trickle down effect and is mostly mechanical,
I just wanted to get the tricky part as isolated as possible.
llvm-svn: 287354
Walter Lee