Selectively disabling value formatter

Hi,
If I have an SBValue for an object whose type has a formatter enabled for it, is there a way to detect this via the Python API, and if so, request an “unmodified” view of the object?

I’ve experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), but the former seems to always return false, and the latter gives me the same list of children as the original value.

Thanks!

Hi,
If I have an SBValue for an object whose type has a formatter enabled for it, is there a way to detect this via the Python API, and if so, request an “unmodified” view of the object?

There definitely is a way for synthetic children, as you discovered below
For type formats, you can simply set the format on the SBValue on an individual basis (SBValue::SetFormat)
As for summaries, no, there is no way, as that would be nonsensical (don’t like the summary? just don’t ask for it - but there’s no meaning to getting the summary of a value once you disabled its summary)

I’ve experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), but the former seems to always return false, and the latter gives me the same list of children as the original value.

Do you have a reproduction case I can look at?
GetNonSyntheticValue() returning self is correct behavior if IsSynthetic() == False; but if there really is a synthetic provider attached to the object, IsSynthetic() should definitely return True

Thanks!


lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Thanks,
- Enrico
:envelope_with_arrow: egranata@.com :phone: 27683

Hi,
If I have an SBValue for an object whose type has a formatter enabled for
it, is there a way to detect this via the Python API, and if so, request an
"unmodified" view of the object?

There definitely is a way for synthetic children, as you discovered below
For type formats, you can simply set the format on the SBValue on an
individual basis (SBValue::SetFormat)
As for summaries, no, there is no way, as that would be nonsensical (don’t
like the summary? just don’t ask for it - but there’s no meaning to getting
the summary of a value once you disabled its summary)

Yes, this is about synthetic children. Summaries are not a problem.

I've experimented with value.IsSynthetic() and
value.GetNonSyntheticValue(), but the former seems to always return false,
and the latter gives me the same list of children as the original value.

Do you have a reproduction case I can look at?

My setup is kinda complicated, I want to make sure I am using the API
correctly before attempting to create a self-contained repro case.

GetNonSyntheticValue() returning self is correct behavior if IsSynthetic()
== False; but if there really is a synthetic provider attached to the
object, IsSynthetic() should definitely return True

Whose IsSynthetic() is supposed to return True,- the parent's or the
child's?
And on which object should I be calling GetNonSyntheticValue()? (I assume
on the parent?)

Vadim

That’s fair. Can you at least try to describe what you’re trying to do and the data types involved in this?

What do you mean with this?
The model is that you have an SBValue, and that SBValue could be backed by a synthetic value. If you want, you can LLDB not to prefer synthetic values - which changes the way the current SBValue works - or for the same backing variable, give you a non-synthetic SBValue, which is what GetNonSyntheticValue() does

Parent/child should have nothing to do with this, unless I am misunderstanding you

Thanks,
- Enrico
:envelope_with_arrow: egranata@.com :phone: 27683

This was a problem way back in June '15 and Enrico fixed it. Which
version of LLDB are you using?

lldb-340.4.119 (OSX 10.11.3)

lldb-340.4.119 (OSX 10.11.3)

I have no idea what that number means. May be Enrico can figure if
that build has the fix or not.

In your scenario, the SBValue for the vector is synthetic; the SBValue instances for each of the vector elements are not synthetic (well, unless, they are themselves vectors or other things with synthetic providers)

Does that match what you’re seeing?

Thanks,
- Enrico
:envelope_with_arrow: egranata@.com :phone: 27683

I have a hard time recalling which fix that was, I can look up old logsWith that said, if the fix happened in June ’15, it’s unlikely to be in lldb-340

I would encourage you to use trunk LLDB and see if that works better in your use case

Thanks,
- Enrico
:envelope_with_arrow: egranata@.com :phone: 27683

I think this one: http://llvm.org/viewvc/llvm-project?view=revision&revision=240578

Yeah, I don’t think that that change made into lldb-340

That might be the root cause of Vadim’s issue. Thanks for pointing that out Siva.

Thanks,
- Enrico
:envelope_with_arrow: egranata@.com :phone: 27683