https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716
Bug ID: 100716
Summary: member function template parameter not printed in
candidate list
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
CC: paolo.carlini at oracle dot com
Target Milestone: ---
template<typename T>
struct A {
template<typename U>
void f() { }
};
int main() {
A<void>().f(0);
}
With -fpretty-templates this prints:
<source>: In function 'int main()':
<source>:8:6: error: no matching function for call to 'A<void>::f(int)'
<source>:4:12: note: candidate: 'template<class U> void A<T>::f() [with U = U;
T = void]'
[...]
>From the diagnostics, it is not apparent what entity U applies to. Also 'with U
= U' is unnecessary noise. It should be:
<source>:4:12: note: candidate: 'template<class U> void A<T>::f<U>() [with T =
void]'
However,
template<typename T>
struct A {
template<typename U>
void f(U) { }
};
int main() {
A<void>().f();
}
doesn't need to show the function template parameter and should be diagnosed
as:
<source>:4:12: note: candidate: 'template<class U> void A<T>::f(U) [with T =
void]'
However, to distinguish the two cases, cp/error.c would need to determine
whether the function template parameters are deducible. Alternatively, it would
have to look at the list of function parameters and check whether all template
parameters are used somehow (even if not deducible). Not sure whether that's
worth the effort. I assume the current behavior was chosen because the majority
of function template parameters are deducible?
FWIW, I believe the fix for PR50828 was incorrect since it removes the ability
to control whether dump_template_parms called from dump_function_decl returns
early for primary templates or not. I think the flags need to be modified for
printing the function's scope, but not for dump_function_decl.
I'll try to come up with a patch.
