demangle _Z1jI1AEDTcldtfp_cvPT_EES1_

[tromey]

I got this from https://github.com/ianlancetaylor/demangle/issues/3

pokyo. ./target/debug/cppfilt  
_Z1jI1AEDTcldtfp_cvPT_EES1_
j<A>DTcldtfp_cvPT_EES1_

But the right answer is:

pokyo. c++filt _Z1jI1AEDTcldtfp_cvPT_EES1_
decltype (({parm#1}.(operator A*))()) j<A>(A)

or something like that -- llvm differs here and that "parm#1" seems suspicious.

[fitzgen]

I realized that the current code for wrangling scopes of template and function args is wrong for back references that are outside the pointed-to param's scope. This is probably the issue here (or at least one of them).

I've been chewing on what the best solution is, but haven't come to a conclusion yet. I'm thinking either:

• a pass after parsing that resolves tempate and function params to their scope (this is what Ian Taylor's go demangler does, except it potentially repeatedly walks the same AST subtrees, which is surprising but maybe not an issue except for really, really nasty symbols)

• or alternatively save the correct scope for each param in a side table while demangling. We know that the first time we reach a param, we'll be in the correct scope, and it can't be a substitution back reference because its the first time we saw the param. Then every template param back reference will just look up the correct scope in that side table.

[jimblandy]

(The latter sounds better to me.)

[khuey]

Here's another symbol that can't be parsed, probably for similar reasons.

khuey@minbar:~/dev/cpp_demangle$ ./target/debug/cppfilt _ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
_ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
khuey@minbar:~/dev/cpp_demangle$ c++filt _ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
already_AddRefed<mozilla::detail::RunnableFunction<mozilla::ipc::AsyncMinidumpAnalyzer::Run()::{lambda()#1}> >::already_AddRefed()

[jan-auer]

Adding one more example with likely the same cause. Symbol fails to parse:

_Z3MinIiiEDTqultfp_fp0_cl7forwardIT_Efp_Ecl7forwardIT0_Efp0_EEOS0_OS1_

decltype (({parm#1}<{parm#2})?((forward<int>)({parm#1})) : ((forward<int>)({parm#2}))) Min<int, int>(int&&, int&&)

[fitzgen]

The original input will demangle OK, but not the same as libiberty now:

              _Z1jI1AEDTcldtfp_cvPT_EES1_
libiberty:    decltype (({parm#1}.(operator A*))()) j<A>(A)
cpp_demangle: decltype (({parm#1}.operator A*)()) j<A>(A)

[fitzgen]

This one demangles correctly now.

Here's another symbol that can't be parsed, probably for similar reasons.

khuey@minbar:~/dev/cpp_demangle$ ./target/debug/cppfilt
_ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
_ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
khuey@minbar:~/dev/cpp_demangle$ c++filt _ZN16already_AddRefedIN7mozilla6detail16RunnableFunctionIZNS0_3ipc21AsyncMinidumpAnalyzer3RunEvEUlvE_EEEC4Ev
already_AddRefed<mozilla::detail::RunnableFunction<mozilla::ipc::AsyncMinidumpAnalyzer::Run()::{lambda()#1}> >::already_AddRefed()

[fitzgen]

Adding one more example with likely the same cause. Symbol fails to parse:

This one is OK but not quite the same as libiberty:

              _Z3MinIiiEDTqultfp_fp0_cl7forwardIT_Efp_Ecl7forwardIT0_Efp0_EEOS0_OS1_
libiberty:    decltype (({parm#1}<{parm#2})?((forward<int>)({parm#1})) : ((forward<int>)({parm#2}))) Min<int, int>(int&&, int&&)
cpp_demangle: decltype (({parm#1})<({parm#2}) ? (forward<int>)({parm#1}) : (forward<int>)({parm#2})) Min<int, int>(int&&, int&&)

[fitzgen]

Reduced test case for the ?: formatting:

              _Z3abcDTqult3def3ghi3jkl3mnoE
libiberty:    abc(decltype ((def<ghi)?jkl : mno))
cpp_demangle: abc(decltype ((def)<(ghi) ? jkl : mno))

[khuey]

Some of that formatting is probably fixed by #145

[Saldivarcher]

_Z3MinIiiEDTqultfp_fp0_cl7forwardIT_Efp_Ecl7forwardIT0_Efp0_EEOS0_OS1_ demangles the same as libiberty now, but _Z3abcDTqult3def3ghi3jkl3mnoE still does not. :/

[lynnux]

_ZGTtNKSt11logic_error4whatEv fail, but http://demangler.com/ do good: transaction clone for std::logic_error::what() const

[khuey]

_ZGTtNKSt11logic_error4whatEv fail, but http://demangler.com/ do good: transaction clone for std::logic_error::what() const

This is #214 now.

[khuey]

_Z3MinIiiEDTqultfp_fp0_cl7forwardIT_Efp_Ecl7forwardIT0_Efp0_EEOS0_OS1_ demangles the same as libiberty now, but _Z3abcDTqult3def3ghi3jkl3mnoE still does not. :/

The only difference I see for _Z3abcDTqult3def3ghi3jkl3mnoE is how many parentheses are used (we're a little parentheses happy compared to libiberty).