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. >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170623/974751cf/attachment.html>
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170624/3439a4e8/attachment.html>
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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170626/d17e90b3/attachment.html>