Re: [patch] Use the string returned by pretty printer for MI varobjs instead of "{...}"

["André Pönitz" <andre.poenitz@mathematik.tu-chemnitz.de>]

On Tue, May 15, 2012 at 10:28:25AM -0600, Tom Tromey wrote:
> >>>>> "Anton" == xgsa  <xgsa@yandex.ua> writes:
> 
> Anton> The documentation for -var-create says that "for a varobj whose type
> Anton> is some sort of aggregate (e.g., a struct), or for a dynamic varobj,
> Anton> the 'value' attribute will not be interesting". That's not true, as
> Anton> dynamic varobj could also have no children (so its value will be not
> Anton> "{...}" and will be interesting). However I think the string value of
> Anton> varobj that has pretty printer installed should always be returned via
> Anton> MI. It could contain such a useful information as container length or
> Anton> reference count for smart pointers. Moreover, it seems that this
> Anton> information cannot be accessed via MI in another way. This patch
> Anton> contains the proposed fix, documentation and test suite update.
> 
> The patch itself looks fine, but I am not sure whether it should go in.
> 
> My recollection is that the code originally worked this way, but
> Vladimir asked for the "{...}" behavior specifically.

It might affect frontends taking a "{...}" as indication that there
are childrens. In fact, I just found some code using that as a shortcut.

The safe way would be to add a new field 'formatted-value' or similar
with the new value, and perhaps even announce the feature using
-list-features, but I doubt this is worth the trouble.

I am not sure how frontend developers interpret "27.4 gdb/mi Development
and Front Ends", or how much they rely on it in general.

The list of "to be expexted changes" mentions
  * New MI commands may be added.
  * New fields may be added to the output of any MI command.
  * The range of values for fields with specified values, e.g., in_scope
    (see -var-update) may be extended. 

It's not directly obviously to me that this list is meant to be
exhaustive, and even if, whether the third bullet point covers
changing existing values, but there is precedence that changing
values was prefered over adding a new field in the past, so there
is no real reason to not do it again.

Andre'