Re: handle <local-source-name> in demangler

[Ian Lance Taylor <iant at google dot com>]

gkeating@apple.com (Geoffrey Keating) writes:

> Following up on
> <http://gcc.gnu.org/ml/gcc/2006-10/msg00441.html>,
> this patch implements Mark's preferred option,
> 
>     <unqualified-name> ::= <operator-name>
>                        ::= <ctor-dtor-name>
>                        ::= <source-name>
> 		       ::= <local-source-name>   // new
> 
>     <local-source-name> ::= Z <source-name> <discriminator>  // new

The mangling scheme right now has the property that you can
unambiguously tell what to do as you see each character.  This
proposal breaks that property.  Now 'Z' can either be the start of a
<local-source-name> or a <local-name>, which makes <name> ambiguous.
So even though Mark suggested it, I don't think this is a good
encoding.

This shows up in your patch, which does things the demangler code
doesn't do anywhere else, like refer directly to di->n, and save and
restore its position.  And the save and restore does not work
correctly anyhow, since it does not reset di->next_comp.

How about adding a case to local-name?

<local-name> ::= Z <(function) encoding> E <(entity) name> [<discriminator>]
             ::= Z <(function) encoding> E s [<discriminator>]
             ::= Z E <source-name> <discriminator>

This is unambiguous, as 'E' can not appear at the start of <encoding>.
It is very unlikely that we would ever want 'E' to appear at the start
of <encoding>, since it is used in a number of places to mark the end
of a list.

Ian