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.