gimli-rs
Failed demangling with 5.1 while c++filt succeeds
From KDE's konsole, mangled symbol is
_ZSt4swapIN7Konsole12LinePropertyEENSt9enable_ifIXsrSt6__and_IJSt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS6_ESt18is_move_assignableIS6_EEE5valueEvE4typeERS6_SG_
c++filt (version 2.45) prints
std::enable_if<std::__and_<std::__not_<std::__is_tuple_like<Konsole::LineProperty> >, std::is_move_constructible<Konsole::LineProperty>, std::is_move_assignable<Konsole::LineProperty> >::value, void>::type std::swap<Konsole::LineProperty>(Konsole::LineProperty&, Konsole::LineProperty&)
Tried with a recursion limit of 1024, but demangling still fails.
This is the same issue as https://github.com/gimli-rs/cpp_demangle/issues/302#issuecomment-3418942896 and https://github.com/gimli-rs/cpp_demangle/issues/302#issuecomment-3419937451
So far we've chosen not to act here because gcc and LLVM disagree and the way forward is not clear.
TY for the pointers, @khuey. Hard to believe the upstream issue is from 2015 🥹
Did you think about an option for gcc style demangling?
That way applications could first try without and if it doesn't demangle, then try with the gcc option.
Because even if the problem is solved upstream, we will see the "broken" symbols forever.
It's not an option to show the mangled symbols to any end-user (or ask an AI to understand it) - they will always complain or silently think the application creators are incompetent.