[phobos] core.demangle replacing std.demangle?

[Rainer Schuetze]

Sean Kelly wrote:
> On Sep 25, 2010, at 12:49 AM, Rainer Schuetze wrote:
> 
>> Sean Kelly wrote:
>>> I wasn't sure whether to fix std.demangle now that core.demangle works, or to replace/deprecate it.  At the time I just needed something in druntime and I didn't like how std.demangle did everything via string ops. What do you all think?
>>> Sent from my iPhone
>>> On Sep 10, 2010, at 1:12 AM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
>>>> I've noticed that Sean has recently added the core.demangle module to
>>>> druntime.  Does this mean we can deprecate std.demangle?  I've never
>>>> used it myself, but I seem to remember people saying on the NG that it
>>>> is pretty outdated.
>>>>
>>>> -Lars
>>>>
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> I've attached a patch to fix a few issues of core.demangle here: http://d.puremagic.com/issues/show_bug.cgi?id=4852
>>
>> This patch also includes a function to decompress symbols on windows.
> 
> You put the implementation in a struct?  Cheater :-)  That'll let me use actual overloading as well.  And put the function parsing routine outside the type parsing routine.

I don't think there is a way to have circular calls between local 
functions. If you want to keep the parse functions inside the demangle 
function, a local struct containing the local function might help ;-)

I just noticed that local functions are not demangled correctly, they 
just show up as the outer function. parseMangledName should continue if 
parsing the type did not hit the end of the symbol, but you'll somehow 
need to cut off the return type of the outer function, because you'll 
want to see the return type of the local function.

Unfortunately, there is an ambiguity involved 
(http://d.puremagic.com/issues/show_bug.cgi?id=4268), so revisiting the 
name mangling is necessary anyway. Thinking about it again, the return 
type of the outer function should have been dropped from the mangled 
name to start with.

http://d.puremagic.com/issues/show_bug.cgi?id=3043 is another ambiguity 
that is probably valid, too. The current implementation does not 
demangle the test case given there.