This is an archive of the discontinued LLVM Phabricator instance.

[ValueObjectPrinter::GetValueSummaryError] Get summary of non-synthetic values.
AbandonedPublic

Authored by sivachandra on Jun 22 2015, 5:43 PM.

Details

Summary

Without the change, the SBValue object passed to the type summary
script will have a backing synthetic value without any way for the
script to get the non-synthetic values.

Diff Detail

Event Timeline

sivachandra retitled this revision from to [ValueObjectPrinter::GetValueSummaryError] Get summary of non-synthetic values..
sivachandra updated this object.
sivachandra edited the test plan for this revision. (Show Details)
sivachandra added a subscriber: Unknown Object (MLST).

This patch is another way to get around the problem I described here: http://reviews.llvm.org/D10581

I don't think this is the right change. A summary should be getting the most qualified possible value - compatible with user settings - because it makes sense to use that extra information in presenting information. Imagine a summary that wants to say "I have %d elements". If we gave to it the non-synthetic value, it would compute the number of elements in the underlying storage, not the count of user-visible values. That is the wrong way to go at it.

Of course, if a summary truly needs a specific flavor of value, it's fine to ask for that via the SBValue API.

I understand there is an underlying issue with SBValue::GetNonSyntheticValue() - and that is the one we should pursue. I am going to try and look at it today or tomorrow, but please do not commit this patch in the meanwhile.

On Wed, Jun 24, 2015 at 10:46 AM, Enrico Granata <granata.enrico@gmail.com> wrote:

I don't think this is the right change. A summary should be getting the most qualified
possible value - compatible with user settings - because it makes sense to use that extra
information in presenting information. Imagine a summary that wants to say
"I have %d elements". If we gave to it the non-synthetic value, it would compute the number
of elements in the underlying storage, not the count of user-visible values. That is the
wrong way to go at it.

I agree with "A summary should be getting the most qualified possible value" and per my understanding and experimenting with a few examples, this change does not affect it. All this change does is to make the backing ValueObject of the SBValue to be non-synthetic. The SBValue passed to the summary script will still exhibit the incarnation as dictated by the user settings.

Still not the right change.

This will only "fix" the case of summaries - but other instances where people get their hands on an SBValue will still behave incorrectly. The underlying bug is the one in GetNonSyntheticValue(), and I'd prefer to fix that one instead of going around putting band-aids on the rest of the code

As I mentioned on http://reviews.llvm.org/D10581, my feeling is that both should be "fixed" as both of them seem like a problem to me. However, I am OK with at least one of them making it in.

sivachandra abandoned this revision.Jun 24 2015, 6:09 PM
tweakoz added a subscriber: tweakoz.EditedOct 12 2015, 9:29 PM

I am hitting this also (in Xcode7-lldb).
Happens when I want a summary and a synthetic on the same type...

The bug is kind of nasty because there is a strange feedback effect if you try to get non-synthetic child members (used for the synthesis) in a python class provider's update(self) call.

if you look at the example libcxx provider "stdmap_SummaryProvider"
it implies you can use the synthetic to provide the summary (which seems good to me since it reduces duplicated code). Unfortunately this pattern is not working for me. So Right now I have to choose between a synthetic or a summary ;<

Any Idea when a fix will be released ?
How would I work around it in the meantime ?