Jonathan M Davis wrote:
> On Friday 10 September 2010 19:02:53 Benjamin Shropshire wrote:
> 
>> OTOH, anything that is that long is going to be
>> ugly even if you could de-mangle it.
>> 
>
> True, but templates can get pretty long and ugly (even if they're not quite as bad in D since you don't have allocators and whatnot), and sometimes you need to see what they look like. Now, for a stack trace, you probably don't nee to see what the _exact_ type is once it gets that long and nasty - you can probably figure out which function is meant just fine - but for other uses, it could be a bit annoying to not have long template types completely demangled.
>
> 

Maybe the standard should define the "base" mangling and then say something to the effect of: if the mangled name can't be stored in the target object file format it must be compressed or, if it is not compressible enough, hashed in a consistent way so as to fit. If information is lost, the implementation should do so in a way that allow the recovery of enough information to make debugging practical, e.g. by storing the beginning of the name followed by it's hash or my placing a map from hashed symbol names to full symbol names in the debug section.

> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> 

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.

The small attached program complements c++-filt: filter the text input and replace mangled symbols with the demangled names. Maybe something like this can go into a samples/tools folder to be run with rdmd.

Rainer
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: d_filt.d
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100925/cda681f0/attachment.ksh>

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.

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.