https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #32 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #27)
> I think the symbols containing 'Ul' should demangle -- they're lambdas and
> I'd expect my patch to fix those.
I applied your patch first and two more demangled. The one from PR68383:
_ZSt4moveIRZN11trompeloeil13call_modifierINS0_12call_matcherIFiiESt5tupleIJNS0_17predicate_matcherIZNS0_11any_matcherIiEEDaPKcEUlOT_E_ZNS6_IiEES7_S9_EUlRSoE_NS0_13typed_matcherIiEEJEEEEEEEN6mock_c36trompeloeil_tag_type_trompeloeil_135ENS0_12matcher_infoIS3_EEE12handle_throwIZN12_GLOBAL__N_131____C_A_T_C_H____T_E_S_T____6454testEvE4
And the one from PR70909:
_ZSt4moveIRZN11trompeloeil13call_modifierINS0_12call_matcherIFiiESt5tupleIJNS0_17predicate_matcherIZNS0_11any_matcherIiEEDaPKcEUlOT_E_ZNS6_IiEES7_S9_EUlRSoE_NS0_13typed_matcherIiEEJEEEEEEEN6mock_c36trompeloeil_tag_type_trompeloeil_135ENS0_12matcher_infoIS3_EEE12handle_throwIZN12_GLOBAL__N_131____C_A_T_C_H____T_E_S_T____6454testEvE4$_42EENS1_ISJ_SL_NS0_14throw_injectorISN_EEEESB_EUlRSA_E_EONSt16remove_referenceISA_E4typeESB_
> Some of the others certainly look
> suspicious. Did they come out of the compiler, or are they the result of
> fuzzing?
Some came out of a compiler, some from some fuzzers. I just took all of them
reported in the various bug reports. The ones that look like they didn't come
from a fuzzer that still don't demangle with both patches applied are:
- PR70517
_ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_
Different compilers produce a different mangled string. I suspect this is
produced by a buggy compiler.
- PR67738
_ZNK6Common15ConvertingRangeIN5boost12range_detail17transformed_rangeIZN1a1b1cEbEUljE_KSt6vectorIjSaIjEEEEEcvT_IS7_INS4_1dESaISF_EEEEv
Bug claims this used to demangle to:
Common::ConvertingRange<boost::range_detail::transformed_range<a::b::c(bool)::{lambda(unsigned
int)#1}, std::vector<unsigned int, std::allocator<unsigned int> > const>
>::operator a::b::c(bool)::{lambda(unsigned int)#1}<a::d, std::allocator<a::d>
><a::b::c(bool)::{lambda(unsigned int)#1}<a::d, std::allocator<a::d> > >() cons
- PR68700
_ZN8futurizeI13frozen_schemaE5applyIRZN7seastar7shardedIN7service13storage_proxyEE9invoke_onIZZNS6_22init_messaging_serviceEvENKUljN5utils4UUIDEE8_clEjSA_EUlOT_E_6futureIJS0_EEEET0_jSD_EUlvE_JEEESG_SD_DpOT0_
This looks like it comes from a real compiler, dunno what it should demangle
to.
- PR61460
_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeINS_9addressesEINS2_IRFRNS_5eventEP9_cl_eventEINS_14iterator_rangeIPKS7_EEEEEEEENS0_16iterator_adaptorIS3_INSG_IS9_ISC_EEEEEESI_EcvT_ISt6vectorIPS4_SaISN_EEvEEv
The referenced GDB bug claims this comes from clover's libOpenCL in Mesa, but
doesn't state which compiler.
I could leave those out of the test file and keep the bugs open (or reopen if
they were closed as a duplicate of this bug) till we figure out which was what.
The important point (for this bug) is that those symbols don't crash the
demangler anymore.
> IMHO it'd be better to change d_print_comp to take a pointer to non-constant
> demangle_component, rather than use casts in the function.
I am not sure what the coding conventions should be in this case. I would see
it as an implementation detail. Only for d_print_comp is this a (private)
mutable field, for any other function, including the public ones the struct
could be considered unmutable. At least for the (public) fields the caller
cares about.
