mangling type_info for local related types

[Alain Miniussi]

Jim Dehnert wrote:
> 
> > Date: Fri, 26 May 2000 10:54:36 -0700
> > From: Alain Miniussi <alainm at cup.hp.com>
> >
> > By reading the spec, I'am not sure to understand how
> > local types and type_info mangling interfere. It seems that,
> > with the current mangling, we have:
> >
> > struct a_class {};
> >
> > typeid(a_class) -> _ZN6a_classTIE
> 
> yes, except          _ZN7a_classTIE
> 
> > void a_func() {
> >   struct a_class {};
> >   typeid(a_class);   -> _ZZ5a_funcvEN6a_classTIE // local name
> >   typeid(a_class*);  -> _ZNPZ5a_funcvE6a_classTIE // non local
> > };
> >
> > Is that the intended mangling ?
> 
> Similarly, those names have the length wrong (5 instead of correct 6,
> 6 instead of correct 7).
> 
> > Date: Fri, 26 May 2000 14:48:14 -0700
> > From: Alain Miniussi <alainm at cup.hp.com>
> >
> > By the way, I am not sure the current mangling allow to
> > form a pointer to a local struct, only <name> can be local,
> > not <type>, maybe we need a <local-class-enum> production ?
> >
> > <class-enum> ::= <local-class-enum>
> >              ::= ...
> > <local-class-enum> :: Z<function encoding>E<class-enum>[<discriminator>]
> >
> > Also, pointer type are not mentionned in <component-name>.
> 
> Well, it looks to me as if there are a number of issues here.  First,
> just <class-enum-type> is not enough -- couldn't we end up with other
> types as well (e.g. arrays)?

These type (array, pointer etc..) can be considered as modified type
built upon local types. I don't think we need to make the modified
type local.
 
> One possible rule is the following:  Treat all local names as nested
> names, where the first component is the local-name mangling of the
> enclosing function name.  Then typeid(a_func::a_class) becomes:
> 
>         _ZN Z5a_funcvE 6a_class TI E
> 
> This doesn't resolve the question of where to put the P for a pointer
> as in the typeid(a_func::a_class *) example.  Let's talk about the
> issue tomorrow, and likely in two weeks once Alex Samuels has
> distributed the updated description Mark mentioned.
> 
> Jim
> 
> -           Jim Dehnert         dehnert at sgi.com
>                                 (650)933-4272