> I'd like to discuss how mutable types should be handled in varobj.

It turns out to be a little simpler than I thought, assuming my
understanding of the GDB/MI varobj interface is right:

If a varobj mutated, whether a root varobj or not, it should be
listed in the change list as a "type_changed".  However, all its
children varobjs are simply destroyed without further ado, and
they will not be listed in the change list. This means that we
expect the front-end to understand that children varobjs of
a varobj that has mutated are invalid, and thus automatically
destroyed.

With the attached prototype, this is what I get.

  (1) First, creating the varobj and listing its children:

  | -var-create v * v
  | ^done,name="v",numchild="4",value="{...}",type="pck.variant",has_more="0"
  | (gdb)
  | -var-list-children 1 v
  | ^done,numchild="4",children=[child={name="v.disc",exp="disc",numchild="0",value="true",type="boolean"},[snip]],has_more="0"
  | (gdb)

  (2) Second, doing an update after some changes in the value, but
      no mutation (only field "a" in our variant record changed):

  | -var-update v
  | ^done,changelist=[{name="v.a",in_scope="true",type_changed="false",has_more="0"}]
  | (gdb)

  (3) Lastly, doing an update after the value mutated. This time,
      we see that varobj simply reports that the value has mutated
      (type_changed="true"), and just provides the number number of
      children:

  |  -var-update v
  |  ^done,changelist=[{name="v",in_scope="true",type_changed="true",new_type="pck.variant",new_num_children="3",has_more="0"}]
  |  (gdb)

The prototype cannot be applied as is, as it needs to be applied
on top of some other changes that are work-in-progress.  But it
should give a good idea of how I proceeded.

The good thing is that this is fairly localized. I'm also wondering
whether this might be done without a language-dependent hook (see
the first FIXME of ada_varobj_value_has_mutated's description).
Perhaps create_child_with_value could solve my practical problem?
I haven't gone that far yet. I also tried testing the case where
it's a child rather than the root that mutates, but for some reason
the child is not properly described (in a sense similar to what
c_describe_child does), and thus I miss the mutation. So that
feature is untested, but it's just because of a bug I will chase
ASAP.

The unfortunate part, though, is that this is done somewhat in
parallel of the work done to handle pretty-printers. I think it
kind of makes sense that pretty-printers should take precedence
over this treatment. So, I'm somewhat thinking that it's better
that way. I haven't had time to verify that precedence is respected,
however. I just wanted to send the patch for comment...

The careful reader will also notice that I'm having trouble with
figuring out some invariants regarding the `from' and `to' fields
with respect to the `num_children' field... More stuff to be figured
out later...

Thanks,
-- 
Joel