granata.enrico added a comment.

In http://reviews.llvm.org/D11473#211047, @sivachandra wrote:

> On Thu, Jul 23, 2015 at 2:17 PM, Enrico Granata <granata.enr...@gmail.com> 
> wrote:
>
> > - Is there going to be a flag to "type summary add" for setting your new 
> > flag, or is this only meant for internal formatters?
>
>
> I have only envisioned using such an option in scripts. If you feel it would 
> be relevant/complete to expose it in the "type summary flags", I will do it 
> as a follow up unless you want me to do it with this change itself.


It seems like a generally useful option to have, since we're adding this 
ability to the summary, to set it at the command line for a formatter you are 
creating yourself

> > - How do you plan to test it?

> 

> 

> I am testing my change locally by having a type summary script along with a 
> synthetic children provider script which returns 0 children. I will add the 
> same as a test for this patch.


Of course this mode would work just as well for a type which just happens to 
have zero children "organically", as in:

struct S {};
S myS;

I don't think there should be anything specific to synthetic children here, 
even though I see why that's mostly useful there
My general theory would be for synthetic children to be able to fail-safe 
themselves, as in, recognize that some of their preconditions are not met 
(imagine an std::list<T> with a NULL base pointer), and then fall back to 
displaying the actual child values. The issue you run into is that the summary 
is independent of the synthetic children, so you risk getting a mismatch 
between what the summary says and the content you see.
For instance, a list might store its count inline, but then have a bogus 
first-node pointer, so you would get, say, "size =5" and then incorrect 
children.
I have yet to figure out a sustainable strategy for that, but that's way beyond 
the scope of this change.

> > - If anything, maybe replace Print with Expand, to get 
> > ShouldExpandEmptyAggregates(). We are indeed printing the aggregate, just 
> > not "expanding" it

> 

> 

> Will do it.



http://reviews.llvm.org/D11473




_______________________________________________
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

Reply via email to