[Bug c++/105425] New: ambiguous template instantiation with hana::when

[Bug c++/105425] New: ambiguous template instantiation with hana::when

[ed at catmur dot uk]

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

            Bug ID: 105425
           Summary: ambiguous template instantiation with hana::when
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ed at catmur dot uk
  Target Milestone: ---

Simplified:

template<bool> struct when;
template<int> constexpr int B = 1;
template<class, class> struct A;
template<class T, bool K> struct A<T, when<K>> {}; // fallback
template<class C> struct A<C, when<B<0> == 1>> {};
A<int, when<true>> a;

"B<0> == 1" is sufficiently complex (?) to trigger the bug (it doesn't need to
be dependent on C) but "B<0>" on its own isn't.

This affects hana since it uses the when<true> pattern heavily.

Per godbolt 11.3.0 is good, 12.0.1 20220426 is bad.

[Bug c++/105425] ambiguous template instantiation with hana::when

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.0
                 CC|                            |mpolacek at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org
   Last reconfirmed|                            |2022-04-28
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |rejects-valid

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r12-6022-gbb2a7f80a98de3

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Untested fix:

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..cf24d482488 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24276,7 +24276,8 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
            }
        }

-      if (!TREE_TYPE (arg))
+      if (!TREE_TYPE (arg)
+         || TREE_CODE (TREE_TYPE (arg)) == DEPENDENT_OPERATOR_TYPE)
        /* Template-parameter dependent expression.  Just accept it for now.
           It will later be processed in convert_template_argument.  */
        ;

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:509fd16da8528444dccc98cef57a18a295c3f1b4

commit r13-5-g509fd16da8528444dccc98cef57a18a295c3f1b4
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Apr 28 13:10:56 2022 -0400

    c++: partial ordering and dependent operator expr [PR105425]

    Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
    specialization #2 to be more specialized than #1 ultimately because
    dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
    instead of an empty type, and this made unify stop deducing T(2) == 1
    for K during partial ordering for #1 and #2.

    This minimal patch fixes this by making the relevant logic in unify
    treat DEPENDENT_OPERATOR_TYPE like an empty type.

            PR c++/105425

    gcc/cp/ChangeLog:

            * pt.cc (unify) <case TEMPLATE_PARM_INDEX>: Treat
            DEPENDENT_OPERATOR_TYPE like an empty type.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/partial-specialization13.C: New test.

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:38bdf2dccf6a239598ef808ed11a904e5f2a186e

commit r12-8317-g38bdf2dccf6a239598ef808ed11a904e5f2a186e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Apr 28 13:10:56 2022 -0400

    c++: partial ordering and dependent operator expr [PR105425]

    Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
    specialization #2 to be more specialized than #1 ultimately because
    dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
    instead of an empty type, and this made unify stop deducing T(2) == 1
    for K during partial ordering for #1 and #2.

    This minimal patch fixes this by making the relevant logic in unify
    treat DEPENDENT_OPERATOR_TYPE like an empty type.

            PR c++/105425

    gcc/cp/ChangeLog:

            * pt.cc (unify) <case TEMPLATE_PARM_INDEX>: Treat
            DEPENDENT_OPERATOR_TYPE like an empty type.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/partial-specialization13.C: New test.

    (cherry picked from commit 509fd16da8528444dccc98cef57a18a295c3f1b4)

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed.