[llvm-dev] VC C++ demangler

[Rui Ueyama via llvm-dev]

They are LGPL, so I think we cannot use them.

On Tue, Jun 27, 2017 at 1:17 AM, Qian Hong <fracting at gmail.com> wrote:

> Sorry for didn't post earlier, has anyone checked http://mingw-w64.
> sourceforge.net/libmangle/ ?
>
> Also the Wine project has some code which might be useful as reference /
> test case:
>
> https://github.com/wine-mirror/wine/blob/master/dlls/msvcrt/undname.c
> https://github.com/wine-mirror/wine/blob/master/dlls/
> msvcrt/tests/cpp.c#L1098
>
>
>
>
> On Tue, Jun 27, 2017 at 3:53 PM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I uploaded a FYI patch (not intended for submission) as
>> https://reviews.llvm.org/D34667. If you want to take a look and comment
>> on its design, please do so. Thanks!
>>
>> On Fri, Jun 23, 2017 at 5:25 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> Please add me on reviews.  BTW, even differing in whitespace might cause
>>> problems, I know their tools have some builtin assumptions about whitespace
>>> in type names.  How deeply engrained this is is not clear though.
>>>
>>> On Fri, Jun 23, 2017 at 10:10 AM Rui Ueyama via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> FYI, I started writing a demangler. I think I can send an initial patch
>>>> to review in a few days.
>>>>
>>>> On Tue, Jun 20, 2017 at 11:07 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>>
>>>>> On Tue, Jun 20, 2017 at 10:51 AM, Robinson, Paul <
>>>>> paul.robinson at sony.com> wrote:
>>>>>
>>>>>> If it's only whitespace differences, that's easy to accommodate.  If
>>>>>> there are other cases that don't work, maybe don't use this tactic for
>>>>>> those, if we have a good reason for being different.  As they say, don't
>>>>>> throw the baby out with the bathwater.
>>>>>>
>>>>>
>>>>> I'll try to keep the difference only in whitespace.
>>>>>
>>>>>
>>>>>> --paulr
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>>>>>> *Sent:* Tuesday, June 20, 2017 10:39 AM
>>>>>> *To:* Rui Ueyama; Robinson, Paul
>>>>>> *Cc:* Martin J. O'Riordan; llvm-dev at lists.llvm.org
>>>>>> *Subject:* Re: [llvm-dev] VC C++ demangler
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yeah, may well be the case - I don't /think/ LLVM quite matches the
>>>>>> exact syntax of the GCC demangler either (I seem to recall constants as
>>>>>> non-type template parameters were a bit different).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 20, 2017 at 10:36 AM Rui Ueyama <ruiu at google.com> wrote:
>>>>>>
>>>>>> On Tue, Jun 20, 2017 at 10:17 AM, Robinson, Paul <
>>>>>> paul.robinson at sony.com> wrote:
>>>>>>
>>>>>> Just to be clear - once LLVM has its own demangler, it should
>>>>>> probably use it on all platforms, so there'd be no worry about different
>>>>>> behavior between LLVM on Windows and LLVM elsewhere.
>>>>>>
>>>>>> But that said, it's probably still important/worthwhile to make sure
>>>>>> it's consistent with the platform demangler.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally I would be all for a unit test program that verified
>>>>>> against the Windows API when run on Windows, and against canned output on
>>>>>> non-Windows.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That was my preference too, but looks like getting the exact same
>>>>>> results as the Windows API is not that easy nor worthwhile when it comes to
>>>>>> arbitrary formatting rules. For example, IIRC, UnDecorateSymbolName
>>>>>> generates not "int const* const* x" nor "int const * const * x" but "int
>>>>>> const* const * x". This is simply odd, and I'd guess we don't want
>>>>>> to mimic all these corner cases. So mixing our own demangler and the
>>>>>> Windows demangler can cause unnecessary churn.
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
> --
> Regards,
> Qian Hong
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/d5444485/attachment.html>