[Lldb-commits] [PATCH] D30272: Improve data formatter for libstdcpp unique_ptr

[Tamas Berghammer via Phabricator via lldb-commits]

tberghammer added a comment.

In https://reviews.llvm.org/D30272#686061, @jingham wrote:

> I also thought about having the synthetic child provider mark up the special child value objects when it made them.  It bugs me a little but that you couldn't, for instance, have a synthetic child provider that doesn't display a child that is the result of the dereference in its view, but provides one when you do the dereference.  And it looks like we're creating a system where we have somebody - the SCP - that knows what the dereference means to it, but then we lose the connection to that knowledge when we hand it out.


The current system already supports it to have a synthetic child what doesn't displayed by default (can be referenced by name) so we can rely on that functionality to have a child what is the result of the dereference while not in view. We might have to gave it a special name (e.g. "$dereference") to make it easy to access it from the value object but I am not sure if it will be necessary (would certainly make the code simpler and more efficient).

I thought quite a bit about adding a Dereference method the the synthetic child provider but I am not convinced it is a good idea as it would complicate the API for it and I don't see how can we solve the problem I hit with the infinite smart pointer loop when I added a synthetic child displayed by default what contained the dereference of the pointed object without annotating the children itself.

> Explain a bit more why you need to create a copy?  Anything that makes two versions of the same value that we have to keep in sync makes me nervous.  For instance, one of the things we want to do in the future is make write-back possible for synthetic children.  That would allow you to change values of std::vector elements in the Locals view of a GUI debugger (which would naturally be based on SBValues) just like you can with the non-synthetic SBValues.  Also, how would the SCP know to update this copy when you've stepped in the debugger and the dereference now points to another pointee?

Take the following (bit strange) example:

  struct Foo {
    int x;
    int& operator*() { return x; }
  }

If I implement a synthetic child provider for it then it will return the same value object as we would return when accessing the "x" member variable. If we annotate that value object as dereference of parent then it will effect the way we are displaying the "x" member variable even when it is not used through the "operator*". Creating a second separate ValueObject solves this problem by separating the 2 solving this issue. For updating it we will rely on the same logic what is currently used to update other synthetic children after a step what is not backed by an actual variable. My current idea is to create a new ValueObject with the memory address and compiler type copied from the original value object and it will be updated using the Update method of the synthetic child provider.


https://reviews.llvm.org/D30272