[ItaniumDemangle] Fails to demangle special substitution with template arguments (when parsing a conversion operator)

[ioannco]

Issue description

LLVM demangler fails to decode Itanium mangled name

_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
which encodes
foo::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>()
while other demanglers (i.e c++filt) do not fail.

Possible causes

It seems that in llvm/Include/llvm/Demangle/ItaniumDemangle.h:3346 parser has been explicitly told not to try to parse template arguments in the names encoding C-style casts. I did not find any reason why this is illegal in the itanium C++ ABI

Possible patch provided in this pull request

How to reproduce

example.cpp:

#include <iostream>

class foo {
public:
  operator std::string() {return {};};
};

int main() {
  (std::string) foo();
};

$ clang++ example.cpp -o example
$ llvm-nm example | llvm-cxxfilt example

output:

0000000000003dc0 d _DYNAMIC
0000000000004000 d _GLOBAL_OFFSET_TABLE_
00000000000010b0 t _GLOBAL__sub_I_example.cpp
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
                 U std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()@GLIBCXX_3.4.21
                 U std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@GLIBCXX_3.4.21
                 U std::ios_base::Init::Init()@GLIBCXX_3.4
                 U std::ios_base::Init::~Init()@GLIBCXX_3.4
0000000000004049 b std::__ioinit
0000000000002138 r __FRAME_END__
0000000000002004 r __GNU_EH_FRAME_HDR
0000000000004048 D __TMC_END__
000000000000037c r __abi_tag
0000000000004048 B __bss_start
                 U __cxa_atexit@GLIBC_2.2.5
                 w __cxa_finalize@GLIBC_2.2.5
0000000000001080 t __cxx_global_var_init
0000000000004038 D __data_start
0000000000001160 t __do_global_dtors_aux
0000000000003db8 d __do_global_dtors_aux_fini_array_entry
0000000000004040 D __dso_handle
0000000000003da8 d __frame_dummy_init_array_entry
                 w __gmon_start__
                 U __libc_start_main@GLIBC_2.34
0000000000004048 D _edata
0000000000004050 B _end
000000000000120c T _fini
0000000000001000 T _init
00000000000010c0 T _start
0000000000004048 b completed.0
0000000000004038 W data_start
00000000000010f0 t deregister_tm_clones
00000000000011a0 t frame_dummy
00000000000011b0 T main
0000000000001120 t register_tm_clones

demangle of line
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
has failed.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-cxxfilt

Author: Ivan Cheremisenov (ioannco)

# Issue description

LLVM demangler fails to decode Itanium mangled name

_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
which encodes
foo::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>()
while other demanglers (i.e c++filt) do not fail.

Possible causes

It seems that in llvm/Include/llvm/Demangle/ItaniumDemangle.h:3346 parser has been explicitly told not to try to parse template arguments in the names encoding C-style casts. I did not find any reason why this is illegal in the itanium C++ ABI

Possible patch provided in this pull request

How to reproduce

example.cpp:

#include <iostream>

class foo {
public:
  operator std::string() {return {};};
};

int main() {
  (std::string) foo();
};

$ clang++ example.cpp -o example
$ llvm-nm example | llvm-cxxfilt example

output:

0000000000003dc0 d _DYNAMIC
0000000000004000 d _GLOBAL_OFFSET_TABLE_
00000000000010b0 t _GLOBAL__sub_I_example.cpp
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
                 U std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::basic_string()@<!-- -->GLIBCXX_3.4.21
                 U std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::~basic_string()@<!-- -->GLIBCXX_3.4.21
                 U std::ios_base::Init::Init()@<!-- -->GLIBCXX_3.4
                 U std::ios_base::Init::~Init()@<!-- -->GLIBCXX_3.4
0000000000004049 b std::__ioinit
0000000000002138 r __FRAME_END__
0000000000002004 r __GNU_EH_FRAME_HDR
0000000000004048 D __TMC_END__
000000000000037c r __abi_tag
0000000000004048 B __bss_start
                 U __cxa_atexit@<!-- -->GLIBC_2.2.5
                 w __cxa_finalize@<!-- -->GLIBC_2.2.5
0000000000001080 t __cxx_global_var_init
0000000000004038 D __data_start
0000000000001160 t __do_global_dtors_aux
0000000000003db8 d __do_global_dtors_aux_fini_array_entry
0000000000004040 D __dso_handle
0000000000003da8 d __frame_dummy_init_array_entry
                 w __gmon_start__
                 U __libc_start_main@<!-- -->GLIBC_2.34
0000000000004048 D _edata
0000000000004050 B _end
000000000000120c T _fini
0000000000001000 T _init
00000000000010c0 T _start
0000000000004048 b completed.0
0000000000004038 W data_start
00000000000010f0 t deregister_tm_clones
00000000000011a0 t frame_dummy
00000000000011b0 T main
0000000000001120 t register_tm_clones

demangle of line
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
has failed.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Ivan Cheremisenov (ioannco)

# Issue description

LLVM demangler fails to decode Itanium mangled name

_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
which encodes
foo::operator std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>()
while other demanglers (i.e c++filt) do not fail.

Possible causes

It seems that in llvm/Include/llvm/Demangle/ItaniumDemangle.h:3346 parser has been explicitly told not to try to parse template arguments in the names encoding C-style casts. I did not find any reason why this is illegal in the itanium C++ ABI

Possible patch provided in this pull request

How to reproduce

example.cpp:

#include <iostream>

class foo {
public:
  operator std::string() {return {};};
};

int main() {
  (std::string) foo();
};

$ clang++ example.cpp -o example
$ llvm-nm example | llvm-cxxfilt example

output:

0000000000003dc0 d _DYNAMIC
0000000000004000 d _GLOBAL_OFFSET_TABLE_
00000000000010b0 t _GLOBAL__sub_I_example.cpp
0000000000002000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
                 U std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::basic_string()@<!-- -->GLIBCXX_3.4.21
                 U std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::~basic_string()@<!-- -->GLIBCXX_3.4.21
                 U std::ios_base::Init::Init()@<!-- -->GLIBCXX_3.4
                 U std::ios_base::Init::~Init()@<!-- -->GLIBCXX_3.4
0000000000004049 b std::__ioinit
0000000000002138 r __FRAME_END__
0000000000002004 r __GNU_EH_FRAME_HDR
0000000000004048 D __TMC_END__
000000000000037c r __abi_tag
0000000000004048 B __bss_start
                 U __cxa_atexit@<!-- -->GLIBC_2.2.5
                 w __cxa_finalize@<!-- -->GLIBC_2.2.5
0000000000001080 t __cxx_global_var_init
0000000000004038 D __data_start
0000000000001160 t __do_global_dtors_aux
0000000000003db8 d __do_global_dtors_aux_fini_array_entry
0000000000004040 D __dso_handle
0000000000003da8 d __frame_dummy_init_array_entry
                 w __gmon_start__
                 U __libc_start_main@<!-- -->GLIBC_2.34
0000000000004048 D _edata
0000000000004050 B _end
000000000000120c T _fini
0000000000001000 T _init
00000000000010c0 T _start
0000000000004048 b completed.0
0000000000004038 W data_start
00000000000010f0 t deregister_tm_clones
00000000000011a0 t frame_dummy
00000000000011b0 T main
0000000000001120 t register_tm_clones

demangle of line
00000000000011e0 W _ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEv
has failed.

[Michael137]

This fails to demangle when we parse the Sa special substitution in parseType and encounter the template argument IcE while TryParseTemplateArguments == false, as you point out. I suspect this was an untested codepath because with libc++ all types live in an inline namespace (most commonly std::__1), so Clang is never allowed to produce those special substitutions. But with libstdc++ apparently only std::basic_string lives in the __cxx11 namespace, but not std::allocator. So hence we compressed std::allocator but not std::__cxx11::basic_string. See godbolt.

Slightly more self-contained reproducer would be:

namespace std {
template <typename T>
struct allocator {};
}

template<typename T>
struct Bar {};

struct Foo {
    operator Bar<std::allocator<char>>() { return {}; }
};

int main() {
    Foo f;
    (Bar<std::allocator<char>>)f;
    return 0;
}

AFAICT, the reason why TryToParseTemplateArgs exists, is to support cases where we have conversion operators whose result-type contains forward template references. So if you allow parsing template arguments like you propose, I suspect there are cases where we would get confused about which template the forward reference referred to. E.g., (taken from one of the test failures) for _ZN5OuterI4MarpEcvT_I4MerpEEv, we would now demangle to:

Outer<Marp>::operator Marp<Merp>()

instead of:

Outer<Marp>::operator Merp<Merp>()

Nonetheless, this is a bug with the demangler.