[Bug c++/103198] New: ICE for requires requires clause with varadic templates

[Bug c++/103198] New: ICE for requires requires clause with varadic templates

[unlvsur at live dot com]

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

            Bug ID: 103198
           Summary: ICE for requires requires clause with varadic
                    templates
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

[Bug c++/103198] ICE for requires requires clause with varadic templates

[unlvsur at live dot com]

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

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51771&action=edit
Preprocess file

preprocess file

[Bug c++/103198] ICE for requires requires clause with varadic templates

[unlvsur at live dot com]

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

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51772&action=edit
compiler error

[Bug c++/103198] ICE for requires requires clause with varadic templates

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
   Target Milestone|---                         |11.3
                 CC|                            |ppalka at gcc dot gnu.org
   Last reconfirmed|                            |2021-11-11
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Reduced rejects-valid testcase:

template<class T>
struct A {
  T handle;

  template<class U>
  requires requires { handle.f(); }
  void f(U);
};

struct B { void f(); };

int main() {
  A<B> a;
  a.f(0);
}

[Bug c++/103198] ICE for requires requires clause with varadic templates

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:09c24fe42ff2cef3f3291f5a7540a5835c08430c

commit r12-5389-g09c24fe42ff2cef3f3291f5a7540a5835c08430c
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Nov 18 19:32:22 2021 -0500

    c++: implicit dummy object in requires clause [PR103198]

    In the testcase below satisfaction misbehaves for f and g ultimately
    because find_template_parameters fails to notice that the constraint
    'val.x' depends on the template parms of the class template.  In
    contrast, satisfaction works just fine for h.

    The problem seems to come down to a difference in how any_template_parm_r
    handles 'this' vs a dummy object: it walks the TREE_TYPE of the former
    but not the latter, and this causes us to miss the tparm dependencies in
    f/g's constraints since in their case the implicit object parm through
    which we access 'val' is a dummy object.  (For h, since we know it's a
    non-static member function when parsing its trailing constraints, the
    implicit object parm is 'this', not a dummy object.)

    This patch fixes this inconsistency by making any_template_parm_r walk
    into the TREE_TYPE of a dummy object, like it already does for 'this'.

            PR c++/103198

    gcc/cp/ChangeLog:

            * pt.c (any_template_parm_r): Walk the TREE_TYPE of a dummy
            object.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-this1.C: New test.

[Bug c++/103198] ICE for requires requires clause with varadic templates

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:648d5aa56abd2a0ab36403dd1e14dd225402301a

commit r11-9390-g648d5aa56abd2a0ab36403dd1e14dd225402301a
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Nov 18 19:32:22 2021 -0500

    c++: implicit dummy object in requires clause [PR103198]

    In the testcase below satisfaction misbehaves for f and g ultimately
    because find_template_parameters fails to notice that the constraint
    'val.x' depends on the template parms of the class template.  In
    contrast, satisfaction works just fine for h.

    The problem seems to come down to a difference in how any_template_parm_r
    handles 'this' vs a dummy object: it walks the TREE_TYPE of the former
    but not the latter, and this causes us to miss the tparm dependencies in
    f/g's constraints since in their case the implicit object parm through
    which we access 'val' is a dummy object.  (For h, since we know it's a
    non-static member function when parsing its trailing constraints, the
    implicit object parm is 'this', not a dummy object.)

    This patch fixes this inconsistency by making any_template_parm_r walk
    into the TREE_TYPE of a dummy object, like it already does for 'this'.

            PR c++/103198

    gcc/cp/ChangeLog:

            * pt.c (any_template_parm_r): Walk the TREE_TYPE of a dummy
            object.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-this1.C: New test.

    (cherry picked from commit 09c24fe42ff2cef3f3291f5a7540a5835c08430c)

[Bug c++/103198] ICE for requires requires clause with varadic templates

[ppalka at gcc dot gnu.org]

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

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

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

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11.3/12.