Failed demangling with 5.1 while c++filt succeeds

[rockdaboot]

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.

[khuey]

This is the same issue as #302 (comment) and #302 (comment)

So far we've chosen not to act here because gcc and LLVM disagree and the way forward is not clear.

[rockdaboot]

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.

[khuey]

It's not something I'm going to do myself but I would take a PR for it.