On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote: > On 11/19/21 04:53, Matthias Kretz wrote: > > On Thursday, 18 November 2021 20:24:36 CET Jason Merrill wrote: > >> On 11/17/21 17:51, Matthias Kretz wrote: > >>>>> __FUNCTION__ was 'fun<int>' all the time, but __PRETTY_FUNCTION__ was > >>>>> 'void fun(T) [with T = int]'. > >>>> > >>>> Isn't that true for instantiations, as well? > >>> > >>> No, instantiations don't have template args/parms in __FUNCTION__. > >> > >> Hmm, that inconsistency seems like a bug, though I'm not sure whether it > >> should have the template args or not; I lean toward not. The standard > >> says that the value of __func__ is implementation-defined, the GCC > >> manual says it's "the unadorned name of the function". > > > > So you think f1<int> in testsuite/g++.old-deja/g++.ext/pretty3.C needs to > > test for > > > > if (strcmp (function, "f1")) > > > > bad = true; > > > > if (strcmp (pretty, "void f1(T) [with T = int]")) > > > > bad = true; > > I think so.
I just found out that the behavior of __FUNCTION__ and DWARF names is related because both go through lang_decl_name in cp/error.c. I.e by removing the test for pp_c_flag_gnu_v3 in dump_function_name and requesting TFF_NO_FUNCTION_ARGUMENTS from lang_decl_name I turned the __FUNCTION__ string into "f1<T>" / "f1<int>". I can filter the former by rejecting the most general template (the DECL_USE_TEMPLATE in dump_function_name we were wondering about). But I can't turn "f1<int>" into "f1" without adding the test for pp_c_flag_gnu_v3 back in dump_function_name. So far __FUNCTION__ and DWARF names want to be the same string. If you want to keep it like this, let me know how the patch should go: "f1" or "f1<int>" (the latter is the status quo and disambiguates different DWARF strings) The __PRETTY_FUNCTION__ string wants to be "void f1<T>(T) [with T = int]", i.e. with the function tparms, because the template args are marked as explicitly specified. This depends on how the function specialization is declared, i.e. 'template<> void f1(int)' vs 'template<> void f1<int>(int)'. I don't know if I can/want to do anything about that. Is that an acceptable result? I'll send two patches: The first patch is what I'd push. The second restores the diagnostics of specialized function templates. > >> That sounds good: omit defaulted parms only if they don't appear in the > >> signature (other than as another default template argument). > > > > Let me check whether I have the right idea: > > > > I could extend find_typenames (which walks the complete) tree to look for > > TEMPLATE_TYPE_PARM (and the 3 others I don't recall right now). But since > > that walks the *complete* tree, it'll simply find all parms with no > > indication > > whether they appear in the signature. Ideas: > Hmm, since it walks DECL_TEMPLATE_RESULT, I wouldn't expect it to find > template parms that aren't in the function signature. You were right, walking TREE_TYPE (DECL_TEMPLATE_RESULT (t)) does what I need. -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de stdₓ::simd ──────────────────────────────────────────────────────────────────────────
