clang++/g++ disagree on how template arguments in substitutions are resolved about cxx-abi HOT 5 OPEN

I suspect the same problem could occur with function parameter references, though an example would have to be very complicated.

from cxx-abi.

The original mangled name is invalid. The right way to refer to Rangitoto in the substitution would be S1_, not S2_, which is what compilers produce for examples that mangle that way, and the modified mangling is demangled the same way by libstdc++'s demangler and libc++abi's demangler.

We can reach cases that demonstrate the problem in question with an example like this:

template<typename T> void ignore(T*);
struct Rangitoto {};
struct Foobar {};
template<typename T, void(*)(Foobar*)> void hello(T*) {}
template void hello<Rangitoto, ignore<Foobar> >(Rangitoto*);

Everyone mangles this as _Z5helloI9RangitotoXadL_Z6ignoreI6FoobarEvPT_EEEvS4_. However, libstdc++ demangles that to the source declaration, libc++abi demangles it to a function taking Foobar* instead.

In summary, Clang, GCC, ICC, and the libstdc++ demangler all agree that when a S<n>_ refers to a T<n>_, the T<n>_ is interpreted in the context where the S<n>_ appears, not in its original context; only the libc++abi demangler disagrees. Presumably that is the rule we should use, then. However, see the problem under discussion in #106, which points out that this kind of situation is hard to demangle in general.

from cxx-abi.

In summary, Clang, GCC, ICC, and the libstdc++ demangler all agree that when a S<n>_ refers to a T<n>_, the T<n>_ is interpreted in the context where the S_ appears, not in its original context; .. Presumably that is the rule we should use

That's great news. I hope you're able to update the spec text to clarify that.

from cxx-abi.

For the record, the real-life issue that triggered this bug report was:
gimli-rs/cpp_demangle#165 (comment)
In particular this symbol was generated by (some circa-2018 version of) clang++:

_ZN7mozilla6detail12ListenerImplINS_14AbstractThreadEZNS_20MediaEventSourceImplILNS_14ListenerPolicyE0EJNS_13TimedMetadataEEE15ConnectInternalIS2_NS_12MediaDecoderEMS8_FvOS5_EEENS_8EnableIfIXsr8TakeArgsIT1_EE5valueENS_18MediaEventListenerEE4TypeEPT_PT0_SD_EUlS9_E_JS5_EE17ApplyWithArgsImplISL_EENSC_IXsr8TakeArgsISH_EE5valueEvE4TypeERKSH_S9_

llvm-cxxfilt 11.0 demangles it to

mozilla::EnableIf<TakeArgs<mozilla::AbstractThread>::value, void>::Type mozilla::detail::ListenerImpl<mozilla::AbstractThread, mozilla::EnableIf<TakeArgs<void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&)>::value, mozilla::MediaEventListener>::Type mozilla::MediaEventSourceImpl<(mozilla::ListenerPolicy)0, mozilla::TimedMetadata>::ConnectInternal<mozilla::AbstractThread, mozilla::MediaDecoder, void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&)>(mozilla::AbstractThread*, mozilla::MediaDecoder*, void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&))::'lambda'(mozilla::TimedMetadata&&), mozilla::TimedMetadata>::ApplyWithArgsImpl<mozilla::EnableIf<TakeArgs<void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&)>::value, mozilla::MediaEventListener>::Type mozilla::MediaEventSourceImpl<(mozilla::ListenerPolicy)0, mozilla::TimedMetadata>::ConnectInternal<mozilla::AbstractThread, mozilla::MediaDecoder, void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&)>(mozilla::AbstractThread*, mozilla::MediaDecoder*, void (mozilla::MediaDecoder::*)(mozilla::TimedMetadata&&))::'lambda'(mozilla::TimedMetadata&&)>(mozilla::AbstractThread const&, mozilla::TimedMetadata&&)

while c++filt 2.35 fails to demangle it.

Perhaps that version of clang++ mangled the symbol incorrectly. I would have tried to come up with a minimal C++ testcase but I'm not adept at taking a symbol like that and reverse-engineering some minimal C++ code that produces it...

from cxx-abi.

libc++abi demangles it to a function taking Foobar* instead.

I hope someone fixes this. Once that's fixed, it'll be interesting to see if that changes llvm-cxxfilt's demangling of the Mozilla symbol above.

from cxx-abi.