mangling type_info for local related types

[Jim Dehnert]

> 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)?

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