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. --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<mailto:ruiu at google.com>> wrote: On Tue, Jun 20, 2017 at 10:17 AM, Robinson, Paul <paul.robinson at sony.com<mailto: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/20170620/68fcff9f/attachment.html>
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/20170620/cfe99884/attachment.html>
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>