[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcSC_OS7_EUljE_E9_M_invokeERKSt9_Any_dataj

["ian at airs dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
Yes.  The relevant bits in the mangling ABI are

<unresolved-name>
   ::= [gs] <base-unresolved-name>
   ::= sr <unresolved-type> <base-unresolved-name>
   ::= srN <unresolved-type> <unresolved-qualifier-level>+ E
<base-unresolved-name>
   ::= [gs] sr <unresolved-qualifier-level>+ E <base-unresolved-name>

<base-unresolved-name>
   ::= <simple-id>
   ::= on <operator-name>
   ::= on <operator-name> <template-args>
   ::= dn <destructor-name>

<unresolved-qualifier-level> ::= <simple-id>

<simple-id> ::= <source-name> [ <template-args> ]

<source-name> ::= <positive length number> <identifier>


srT_ must be sr <unresolved-type> <base-unresolved-name>, where the T_ is the
<unresolved-type>, so it must be followed by <base-unresolved-name>. 
<base-unresolved-name> can only start with a digit or "on" or "dn".  So I see
no way that srT_cl could meet the requirements of the ABI.  It has to be
srT_oncl, where the "on" is needed to indicate that "cl" is an operator name.

That said, GCC is not crazy, as there is no other way to parse this.  The
result is unambiguous.  But it doesn't meet the documented standard.

I think the bug may be that cp/mangle.c:write_member_name needs to check
IDENTIFIER_OPNAME_P and print "on" if it is true, as write_expression does. 
But I'm not sure.