spyffe added a subscriber: spyffe.
spyffe added a comment.
This patch failed to compile. I fixed it with r251083.
Sean
Repository:
rL LLVM
http://reviews.llvm.org/D13657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llv
This patch failed to compile. I fixed it with r251083.
Sean
> On Oct 22, 2015, at 5:05 PM, Phabricator via lldb-commits
> wrote:
>
> +BStream stream;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists
This revision was automatically updated to reflect the committed changes.
Closed by commit rL251080: Summary provider for char. (authored by dperchik).
Changed prior to commit:
http://reviews.llvm.org/D13657?vs=37487&id=38187#toc
Repository:
rL LLVM
http://reviews.llvm.org/D13657
Files:
l
granata.enrico accepted this revision.
granata.enrico added a comment.
This revision is now accepted and ready to land.
Fine to get it in
http://reviews.llvm.org/D13657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/
evgeny777 updated this revision to Diff 37487.
evgeny777 added a comment.
Updated: callback is checked for null + explicit construction
http://reviews.llvm.org/D13657
Files:
include/lldb/API/SBTypeSummary.h
source/API/SBTypeSummary.cpp
Index: source/API/SBTypeSummary.cpp
==
granata.enrico added a comment.
So, if you do the explicit constructor change and handle the case of a nullptr
Callback I think it should be good to go. Looking forward to it!
Comment at: source/API/SBTypeSummary.cpp:157
@@ +156,3 @@
+SBStream stream
evgeny777 added inline comments.
Comment at: source/API/SBTypeSummary.cpp:157
@@ +156,3 @@
+SBStream stream;
+if (!cb(valobj.GetSP(), &opt, stream))
+return false;
granata.enri
granata.enrico added inline comments.
Comment at: source/API/SBTypeSummary.cpp:155
@@ +154,3 @@
+ new CXXFunctionSummaryFormat(options,
+ [cb] (ValueObject& valobj, Stream& stm, const
TypeSummaryOptions& opt) -> bool {
+
evgeny777 added a comment.
One question: CreateWithCallback and CreateWithSummaryString do not require
Python support and can be used with LLDB_DISABLE_PYTHON. May be it makes sense
to remove conditional compilation, like it is done here:
http://reviews.llvm.org/D13577
Commen
granata.enrico added inline comments.
Comment at: source/API/SBTypeSummary.cpp:155
@@ +154,3 @@
+ new CXXFunctionSummaryFormat(options,
+ [cb] (ValueObject& valobj, Stream& stm, const
TypeSummaryOptions& opt) -> bool {
+
granata.enrico added a comment.
Admittedly way simpler than my original idea. +1
Having the RTTI support so that these SBTypeSummary objects can actually be
used for anything other than mere creation would be nice.
However, I can fill that gap myself later.
Comment at: source/
evgeny777 updated this revision to Diff 37339.
evgeny777 added a comment.
Looks like can be done much easier
http://reviews.llvm.org/D13657
Files:
include/lldb/API/SBTypeSummary.h
source/API/SBTypeSummary.cpp
Index: source/API/SBTypeSummary.cpp
=
granata.enrico added a comment.
We are not supposed to be inheriting from SB classes, much less introduce
virtual-ness to them (Greg can go in detail about the reasons, the tl;dr is
that it has the potential to be ABI-breaking)
The way one would do that is to have a typedef akin to (and after f
evgeny777 added a comment.
Yes, I'm interested.
Imagine I have:
SBTypeSummary::CreateCxxFunctionSummary( ... )
How am I supposed to pass the callback there? Or this should be done by means
of introducing some base class, like SBTypeSummaryFormatter and deriving custom
formatters from this c
granata.enrico added a comment.
Currently I don't think SBTypeSummary allows for defining formatters backed by
a CXXFunctionSummaryFormat
It would, however, be a great addition to our API. Is it a change you're
interested in working on?
If so, the easy part is going to be introducing LLVM-style
evgeny777 added a comment.
I thought this would be a nice feature, as I'm long term gdb user and gdb also
evaluates chars as code and value.
MI private category sounds good, but I have concerns on implementing it
properly. For instance SBTypeSummary can create string, function and script
summar
granata.enrico added a comment.
The consistency argument is not entirely unfair.
I would claim that Unicode is a more complex beast than plain ASCII, so it
makes sense to go the extra mile in giving you details in that case, compared
to the simpler char case.
If the only reason you're pursuing
evgeny777 added a comment.
Ok, I see
MI historically has this code + value printing and test cases covering it.
By the way char16_t and char32_t summary providers also print code and value,
in case you don't know.
http://reviews.llvm.org/D13657
___
granata.enrico requested changes to this revision.
granata.enrico added a comment.
This revision now requires changes to proceed.
Truth be told, I find this notation (numeric value + printable character) to be
heavy and somewhat redundant
I would be happier with a model where printable character
evgeny777 created this revision.
evgeny777 added a reviewer: granata.enrico.
evgeny777 added subscribers: lldb-commits, KLapshin.
This patch enables type summary for 'char' type. Let's suppose we have:
**char c = 'h'; **
Current revision evaluates c as:
**(char) $0 = 'h'**
After this patch (10
20 matches
Mail list logo
