Mangling issues from today's meeting

[Alain Miniussi]

Jim Dehnert wrote:
> 
> In today's C++ ABI meeting, we agreed that it was desirable to make
> two changes in the substitution algorithm for mangling.  Since they're
> significant, and some key people weren't there, I'll raise them in
> email and listen for howls...
> 
>  1) To eliminate even the theoretical need to do a full unsubstituted
>     mangling to get the length, we want to change the rule that
>     substitution only occurs if it shortens the unsubstituted name.
>     Instead, we want to say that (a) builtin types, and (b) template
>     parameters are never substituted (and don't go into the dictionary
>     for numbering), but everything else is always substituted without
>     regard to length.

I did that proposal a few time ago, so I am not going to say I am
against 
it :-) Still, I implemented it untill then and it's not really an issue:
you can store the size of the encoding of the entities when you process 
then (and store the suze along with the entity in the indexed structure
you 
use to figure out the later substitution indexes), later, when
processing 
an enclosing entity, you need to look if the subcomponents can be
subsituted,
you have access to the sinze of the full mangling of substituable
subcompnent
and can use it to compute the size of the full mangling of the compound
entity.

Still, assuming that the code contains mostly 1 char name, it only save
one
char per substitution, so the complication is probably not worth the
trouble.
 
>     There is a residual issue that didn't come up at the time:  does
>     (a) include qualified builtin types like "const int"?  If sometimes
>     but not always, where do we put the line?  I think that at least
>     vendor-defined qualifiers should cause substitution.

If we choose to "always" substitute without considering the potential 
one char saving, I don't see the point in trying to save that space here
(especialy since we decided to substitute <cv1>...<cvn><type> and 
<type> but not <cvk>..<cvn><type>).
 
>  2) The numbering of substitution entities is defined as most recent
>     first.  The original reason for that was so that a particular
>     entity, once mangled as part of one name, could be mangled the
>     same way as part of another name.  A month or so ago, we determined
>     that this doesn't (and can't) work, and eliminated duplicates in
>     the substitution dictionary on this basis.
> 
>     Numbering the entities backwards, however, has the effect that even
>     within a single name, the substitution for a particular entity is
>     always changing.  Although the implementation difference is trivial,
>     the names would be easier for a mere human to read and explain if
>     the numbering was forwards, i.e. the first one encountered is
>     always S_, the second is S0_, etc.
> 
> Anyone have comments on either of these changes?  If so, please explain.
> Otherwise, I'll make the changes early next week.
> 
> Jim
> 
> -               Jim Dehnert  x3-4272