From: Matthias Kretz <m.kretz@gsi.de>
To: <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com>
Subject: [PATCH 0/2] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute)
Date: Fri, 26 Nov 2021 16:23:43 +0100 [thread overview]
Message-ID: <1800263.tdWV9SEqCh@excalibur> (raw)
In-Reply-To: <47662158-37ba-457a-ba02-fd4c9aaaae31@redhat.com>
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
──────────────────────────────────────────────────────────────────────────
next prev parent reply other threads:[~2021-11-26 15:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 12:21 [PATCH v3] c++: Add gnu::diagnose_as attribute Matthias Kretz
2021-07-23 8:58 ` [PATCH v4] " Matthias Kretz
2021-08-17 18:31 ` Jason Merrill
2021-11-08 16:40 ` [RFC] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute) Matthias Kretz
2021-11-08 20:00 ` Matthias Kretz
2021-11-16 20:25 ` Jason Merrill
2021-11-16 20:42 ` Matthias Kretz
2021-11-16 20:49 ` Jason Merrill
2021-11-16 20:51 ` Matthias Kretz
2021-11-17 6:09 ` Jason Merrill
2021-11-17 9:04 ` Matthias Kretz
2021-11-17 18:25 ` Jason Merrill
2021-11-17 22:51 ` Matthias Kretz
2021-11-18 19:24 ` Jason Merrill
2021-11-19 9:53 ` Matthias Kretz
2021-11-19 12:02 ` Matthias Kretz
2021-11-19 22:26 ` Jason Merrill
2021-11-19 23:11 ` Matthias Kretz
2021-11-26 15:23 ` Matthias Kretz [this message]
2021-11-26 15:24 ` [PATCH 1/2] c++: Print function template parms when relevant Matthias Kretz
2021-12-02 8:35 ` [PATCH v2 " Matthias Kretz
2021-11-26 15:24 ` [PATCH 2/2] c++: Print function template parms when relevant [part 2] Matthias Kretz
2021-09-08 2:21 ` [PATCH v4] c++: Add gnu::diagnose_as attribute Jason Merrill
2021-11-15 0:35 ` [PATCH v5] " Matthias Kretz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1800263.tdWV9SEqCh@excalibur \
--to=m.kretz@gsi.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).