This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch / RFC] PR 50828
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 24 Sep 2012 16:34:49 +0200
- Subject: [Patch / RFC] PR 50828
Hi,
some time ago Jon filed this diagnostic enhancement PR: explaining it
requires a bit, please be patient, if you can ;)
Essentially, we are comparing a "note" emitted for
template<typename T>
struct A {
template<typename U>
void f() { }
};
int main() {
A<void> a;
a.f(0);
}
vs the version of the "note" when f isn't a template:
template<typename T>
struct A {
void f() { }
};
int main() {
A<void> a;
a.f(0);
}
In the latter case we have:
50828_2.C:3:10: note: void A<T>::f() [with T = void]
whereas in the former we have:
50828_1.C:4:12: note: template<class U> void A::f() [with U = U; T = void]
Note: no <T> after A. This seems an inconsistency (and the T mentioned
by the text between square brackets becomes quite mysterious).
Now, the issue appears to boil down to the way we are calling
dump_function_decl: in the non-template case we call it from dump_decl
simply as:
dump_function_decl (t, flags);
whereas in the template case we call it from dump_template_decl as:
dump_function_decl (t, flags | TFF_TEMPLATE_NAME);
then the TFF_TEMPLATE_NAME is propagated until the final
dump_template_parms which returns immediately when sees it and doesn't
print the '<T>'. Calling dump_function_decl in the same way in both
cases, per the attached patchlet, certainly avoids the inconsistency in
this specific case (and passes the testsuite FWIW) but I'm not sure it's
always correct. What do you think? Any tests I could compile by hand to
check that we aren't breaking anything?
Thanks!
Paolo.
////////////////////////
Attachment:
patch_50828_draft
Description: Text document