mbox series

[0/2] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute)

Message ID 1800263.tdWV9SEqCh@excalibur
Headers
Series c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute) |

Message

Matthias Kretz Nov. 26, 2021, 3:23 p.m. UTC 
  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.