RFC: how to handle mutable types in varobj?

[Joel Brobecker <brobecker@adacore.com>]

Hello,

I'd like to discuss how mutable types should be handled in varobj.
Here is one example involving Ada, but perhaps some other languages
have them too. So, consider the case of a variant record, declared
as follow:

   type Variant (Disc : Boolean := True) is
   record
      A : Integer;
      case Disc is
         when True =>
            Yes : Boolean;
            No : Boolean;
         when False =>
            D : Integer;
      end case;
   end record;

This is a record where the number of components depends on the value
of the discriminant (`Disc' in this case). If the discrimant is True,
it has 4 components: `Disc', `A', as well as `Yes' and `No'. But if
the discriminant is False, it only has 3 components now: `Disc' and
`A', as before, and now `D'.

The trouble with varobj starts when the value of the discriminant
changes during the lifetime of the variable, which is legal in this
case.  If I create a varobj with a variable whose discrimant is True,
then step a few lines until the discriminant changes, and then request
an update,  what should happen? In particular, if I had also listed
the varobj's children, what should happen of them?

In this situation, we go from a varobj with 4 children, to a varobj
with 3 children, 2 of them still having the same type, two old
children having disappeared, and one new child having appeared.

At the front-end level, what should we display at the end of the
-var-update command? We have several elements to consider:

  (1) The root varobj itself
      I imagine that this varobj should be listed in the changed list.
      As far as I can tell from the documentation, probably with
      the `type_changed' attribute, and probably the new number of
      children.

  (2) The "unchanged" children `Disc' and `A', whose type have changed.

  (3) The children varobj that have now disappeared.
      Should the front-end be told somehow that they have disappeared?
      Or do they infer this from the `type_changed' attribute?

  (4) The new children varobj
      I don't think they should be listed in the changed list,
      since their value is new.

The thing is, I am wondering if we should include any of the varobj's
children at all. Whether listing (1) with `type_changed' would be
sufficient.

Purely based on the reading of the documentation and then the code,
I think that mutable types haven't been considered in the original
design - although perhaps the authors of the original design aren't
around anymore. It also seems that support for Python pretty-printing
has been crafted on to varobj, and indirectly introduced the notion
of dynamicity, which is probably similar in some ways to our mutability.
But I am also guessing that this support was implemented in a way
that kept things compatible at the GDB/MI level. As a result, I am
having a hard time building a good overal picture of how things work,
partly because there are so many flags: children_requested, from, to,
type_changed, updated, changedm children_changed, etc.

Rather than redesign the whole thing, I am wondering if we can
expand a little bit on the Python dynamic properties and create
the notion of mutability that we could use for both types that
have a pretty-printer as well as types that are genuinely mutable.

Thoughts?

Thanks!
-- 
Joel