Re: [PATCH 8/9] class-local typedef substitutions

[Pedro Alves <palves@redhat.com>]

On 09/21/2012 08:31 PM, Tom Tromey wrote:
> Tom> This patch implements class-local typedef substitutions for the C++
> Tom> type printer.  That is, when printing a type, gdb will now look at
> Tom> template argument names (if any) and typedefs defined in the class
> Tom> body, and substitute those names when printing type names.
> 
> More testing revealed an oddity in this code (a latent bug exposed by
> the subsequent Python patch); and the fix I chose required some changes
> to some MI test cases as well.  The particular change was that
> previously gdb could emit "long int" but now it will emit just "long" --
> I consider this to be an ok (perhaps even preferable) change.

I'm confused and curious at why such a change would be necessary.  I
couldn't find it from a quick look over the patch.
Can you expand a little?  Does this also affect the CLI?

Why expect both long and "long int"?  Is this compiler / debug format
dependent, perhaps?

>  mi_list_varobj_children {struct_declarations.long_array --all-values} {
> -    {struct_declarations.long_array.0 0 0 "long int" 1234}
> -    {struct_declarations.long_array.1 1 0 "long int" 2345}
> -    {struct_declarations.long_array.2 2 0 "long int" 3456}
> -    {struct_declarations.long_array.3 3 0 "long int" 4567}
> -    {struct_declarations.long_array.4 4 0 "long int" 5678}
> -    {struct_declarations.long_array.5 5 0 "long int" 6789}
> -    {struct_declarations.long_array.6 6 0 "long int" 7890}
> -    {struct_declarations.long_array.7 7 0 "long int" 8901}
> -    {struct_declarations.long_array.8 8 0 "long int" 9012}
> -    {struct_declarations.long_array.9 9 0 "long int" 1234}
> -    {struct_declarations.long_array.10 10 0 "long int" 3456}
> -    {struct_declarations.long_array.11 11 0 "long int" 5678}
> +    {struct_declarations.long_array.0 0 0 "long( int)?" 1234}
> +    {struct_declarations.long_array.1 1 0 "long( int)?" 2345}
> +    {struct_declarations.long_array.2 2 0 "long( int)?" 3456}
> +    {struct_declarations.long_array.3 3 0 "long( int)?" 4567}
> +    {struct_declarations.long_array.4 4 0 "long( int)?" 5678}
> +    {struct_declarations.long_array.5 5 0 "long( int)?" 6789}
> +    {struct_declarations.long_array.6 6 0 "long( int)?" 7890}
> +    {struct_declarations.long_array.7 7 0 "long( int)?" 8901}
> +    {struct_declarations.long_array.8 8 0 "long( int)?" 9012}
> +    {struct_declarations.long_array.9 9 0 "long( int)?" 1234}
> +    {struct_declarations.long_array.10 10 0 "long( int)?" 3456}
> +    {struct_declarations.long_array.11 11 0 "long( int)?" 5678}
>  } "listing of names and values of children"

>  mi_list_varobj_children "psnp->long_ptr" {
> -    {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long int \*\*\*}}
> +    {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long( int)? \*\*\*}}
>  } "get children of psnp->long_ptr"
>  

-- 
Pedro Alves