[llvm-dev] VC C++ demangler

[Rui Ueyama via llvm-dev]

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>