[Bug c++/100716] New: member function template parameter not printed in candidate list

[Bug c++/100716] New: member function template parameter not printed in candidate list

[kretz at kde dot org]

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.

[Bug c++/100716] member function template parameter not printed in candidate list

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716

--- Comment #1 from Matthias Kretz (Vir) <kretz at kde dot org> ---
With -fno-pretty-templates both test cases do print the <U> template_parms.
That's because in dump_function_decl, without flag_pretty_templates, t isn't
generalized and thus is not considered a primary template. And
dump_template_parms only returns early if primary is true.

[Bug c++/100716] member function template parameter not printed in candidate list

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716

--- Comment #2 from Matthias Kretz (Vir) <kretz at kde dot org> ---
I'd like to revise my opinion above. dump_template_decl should never print the
template parameter list of functions. I.e. it should be 'template<class U> f()'
not 'template<class U> f<U>()'. Because it's also declared without the template
parameter list, independent of whether the template parameter is deducible from
the function arguments or not. That means the -fno-pretty-templates output
needs to be fixed and the 'T = T' part needs to disappear.

[Bug c++/100716] member function template parameter should never be printed in candidate list and "T = T" should never be shown in substitutions

[kretz at kde dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716

--- Comment #3 from Matthias Kretz (Vir) <kretz at kde dot org> ---
Created attachment 50877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50877&action=edit
proposed patch

Ensure dump_template_decl for function templates never prints template
parameters after the function name (it did with -fno-pretty-templates)
and skip output of irrelevant & confusing "[with T = T]" in
dump_substitution.

gcc/cp/ChangeLog:

        PR c++/100716
        * error.c (dump_template_bindings): Include code to print
        "[with" and ']', conditional on whether anything is printed at
        all. This is tied to whether a semicolon is needed to separate
        multiple template parameters. If the template argument repeats
        the template parameter (T = T), then skip the parameter.
        (dump_substitution): Moved code to print "[with" and ']' to
        dump_template_bindings.
        (dump_function_decl): Partial revert of PR50828, which masked
        TFF_TEMPLATE_NAME for all of dump_function_decl. Now
        TFF_TEMPLATE_NAME is masked for the scope of the function and
        only carries through to dump_function_name.
        (dump_function_name): Avoid calling dump_template_parms if
        TFF_TEMPLATE_NAME is set.

gcc/testsuite/ChangeLog:

        PR c++/100716
        * g++.dg/diagnostic/pr100716.C: New test.
        * g++.dg/diagnostic/pr100716-1.C: Same test with
        -fno-pretty-templates.
---
 gcc/cp/error.c                               | 59 +++++++++++++++-----
 gcc/testsuite/g++.dg/diagnostic/pr100716-1.C | 54 ++++++++++++++++++
 gcc/testsuite/g++.dg/diagnostic/pr100716.C   | 54 ++++++++++++++++++
 3 files changed, 152 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/pr100716-1.C
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/pr100716.C

[Bug c++/100716] member function template parameter should never be printed in candidate list and "T = T" should never be shown in substitutions

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:c33ec196aa713c62d73907dc8f9e57d7ab2e4e4b

commit r12-1100-gc33ec196aa713c62d73907dc8f9e57d7ab2e4e4b
Author: Matthias Kretz <kretz@kde.org>
Date:   Thu May 27 17:25:37 2021 +0200

    c++: Output less irrelevant info for function template decl [PR100716]

    Ensure dump_template_decl for function templates never prints template
    parameters after the function name (it did with -fno-pretty-templates)
    and skip output of irrelevant & confusing "[with T = T]" in
    dump_substitution.

    gcc/cp/ChangeLog:

            PR c++/100716
            * error.c (dump_template_bindings): Include code to print
            "[with" and ']', conditional on whether anything is printed at
            all. This is tied to whether a semicolon is needed to separate
            multiple template parameters. If the template argument repeats
            the template parameter (T = T), then skip the parameter.
            (dump_substitution): Moved code to print "[with" and ']' to
            dump_template_bindings.
            (dump_function_decl): Partial revert of PR50828, which masked
            TFF_TEMPLATE_NAME for all of dump_function_decl. Now
            TFF_TEMPLATE_NAME is masked for the scope of the function and
            only carries through to dump_function_name.
            (dump_function_name): Avoid calling dump_template_parms if
            TFF_TEMPLATE_NAME is set.

    gcc/testsuite/ChangeLog:

            PR c++/100716
            * g++.dg/diagnostic/pr100716.C: New test.
            * g++.dg/diagnostic/pr100716-1.C: Same test with
            -fno-pretty-templates.

[Bug c++/100716] member function template parameter should never be printed in candidate list and "T = T" should never be shown in substitutions

[mkretz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100716

Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |mkretz at gcc dot gnu.org
   Target Milestone|---                         |12.0
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
Resolved by r12-1100-gc33ec196aa713c62d73907dc8f9e57d7ab2e4e4b. I don't think a
backport should be done.