From: Matthias Kretz <m.kretz@gsi.de>
To: <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com>
Subject: Re: [RFC] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute)
Date: Fri, 19 Nov 2021 13:02:33 +0100 [thread overview]
Message-ID: <1716752.eMUbO1HJkO@excalibur> (raw)
In-Reply-To: <2941803.SbB2uZ23bb@excalibur>
On Friday, 19 November 2021 10:53:27 CET Matthias Kretz wrote:
> > >> Ah, you're trying to omit defaulted parms from the <list>? I'm not
> > >> sure
> > >> that's necessary, leaving them out of the [with ...] list should be
> > >> sufficient.
> > >
> > > I was thinking about all the std::allocator defaults in the standard
> > > library. I don't want to see them. E.g. vector<int>::clear() on const
> > > object:
> > >
> > > error: passing 'const std::vector<int>' as 'this' argument discards
> > > qualifiers [...]/stl_vector.h:1498:7: note: in call to 'void
> > > std::vector<_Tp, _Alloc>::clear() [with _Tp = int; _Alloc =
> > > std::allocator<int>]'
> > >
> > > With my patch the last line becomes
> > > [...]/stl_vector.h:1498:7: note: in call to 'void
> > > std::vector<_Tp>::clear() [with _Tp = int]'
> > >
> > >
> > > Another case I didn't consider before:
> > >
> > > template <class T, class U = int> struct A {
> > >
> > > [[deprecated]] void f(U);
> > >
> > > };
> > >
> > > A<float> a; a.f(1);
> > >
> > > With my patch it prints 'void A<T>::f(U) [with T = float]', with your
> > > suggestion 'void A<T, U>::f(U) [with T = float]'. Both are missing
> > > important information in the substitution list, IMHO. Would 'void A<T, U
> > > = int>::f(U) [with T = float]' be an improvement? Or should
> > > find_typenames (in cp/error.c) find defaulted template parms and add
> > > them
> > > to its list? IIUC find_typenames would find all template parms and
> > > couldn't know whether they're defaulted.
> >
> > 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:
>
> 1. Count occurrences: with 2 occurrences, one of them must be a use in the
> signature.
>
> 2. Walk only over TYPE_ARG_TYPES (TREE_TYPE (DECL_TEMPLATE_RESULT (fn))) to
> collect TEMPLATE_TYPE_PARMs.
I tried the latter:
@@ -1641,8 +1652,11 @@ dump_substitution (cxx_pretty_printer *pp,
&& !(flags & TFF_NO_TEMPLATE_BINDINGS))
{
vec<tree, va_gc> *typenames = t ? find_typenames (t) : NULL;
- dump_template_bindings (pp, template_parms, template_args, typenames,
- flags);
+ tree fn_arguments = TYPE_ARG_TYPES (TREE_TYPE (DECL_TEMPLATE_RESULT
(t)));
+ tree used_template_parms = find_template_parameters (fn_arguments,
+ template_parms);
+ dump_template_bindings (pp, template_parms, template_args,
+ used_template_parms, typenames, flags);
}
}
Now in dump_template_bindings it skips all defaulted template_parms that are
not in used_template_parms. Makes this test pass:
template <class T>
struct id
{ using type = T; };
template <class T0, class T1 = int>
struct A
{
template <class U0 = const T1&>
[[deprecated]] static void
f(typename id<U0>::type);
};
int main()
{
A<int>::f(0); // { dg-warning "'static void A<T0>::f\\(typename
id<U0>::type\\) .with U0 = const int&; T0 = int; typename id<U0>::type = const
int&.'" }
}
--
──────────────────────────────────────────────────────────────────────────
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-19 12:02 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 [this message]
2021-11-19 22:26 ` Jason Merrill
2021-11-19 23:11 ` Matthias Kretz
2021-11-26 15:23 ` [PATCH 0/2] " Matthias Kretz
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=1716752.eMUbO1HJkO@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).