[Bug c++/101677] New: [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[Bug c++/101677] New: [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[joeloser93 at gmail dot com]

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

            Bug ID: 101677
           Summary: [11 Regression] Concept with use of incomplete type
                    succeeds on GCC 10.3.0, fails on GCC 11 onward
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joeloser93 at gmail dot com
  Target Milestone: ---

A concept that uses an incomplete type in testing the well-formedness of
calling a function template is well-formed in GCC 10.3.0, but fails in GCC 11
onward (including trunk at the time of this writing).

For example, consider the following:

template<class T>
concept C_bug_with_forward_decl = requires(T& t){
    t.template f<class S>();
};

struct good {
    template<class T> auto f() -> void {}
};

static_assert(C_bug_with_forward_decl<good>); // works in GCC 10.3.0, fails on
GCC 11 onward

This bug can be worked around by using a complete type instead when defining
the concept. For example:

struct U{};
template<class T>
concept C_workaround = requires(T& t){
    t.template f<U>();
};

static_assert(C_workaround<good>); // works on GCC 10.3.0 and GCC 11 onward

See it live at https://godbolt.org/z/h7GzqGhYn

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11 Regression] Concept     |[11/12 Regression] Concept
                   |with use of incomplete type |with use of incomplete type
                   |succeeds on GCC 10.3.0,     |succeeds on GCC 10.3.0,
                   |fails on GCC 11 onward      |fails on GCC 11 onward
      Known to work|                            |10.3.0
   Target Milestone|---                         |11.3
           Keywords|                            |rejects-valid

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-07-30

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>This bug can be worked around by using a complete type instead when defining the concept. 

It does not even have to be complete type; just defined before.
So adding:
class S;
at the begining causes GCC to accept the code.

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[joeloser93 at gmail dot com]

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

--- Comment #2 from Joe Loser <joeloser93 at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> >This bug can be worked around by using a complete type instead when defining the concept. 
> 
> It does not even have to be complete type; just defined before.
> So adding:
> class S;
> at the begining causes GCC to accept the code.

Yep, you're right. That's actually what I use in my codebase as a workaround. I
misspoke in the description -- sorry about that. Updated Godbolt link is at
https://godbolt.org/z/KGq48WYq4

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:1de6612d994ada8edaab18bbc6afd8e9a57413aa

commit r12-7997-g1de6612d994ada8edaab18bbc6afd8e9a57413aa
Author: Jason Merrill <jason@redhat.com>
Date:   Sun Mar 27 22:31:51 2022 -0400

    c++: elaborated-type-spec in requires-expr [PR101677]

    We were failing to declare class S in the global namespace because we were
    treating the requires-expression parameter scope as a normal block scope,
so
    the implicit declaration went there.

    It seems to me that the requires parameter scope is more like a function
    parameter scope (not least in the use of the word "parameter"), so let's
    change the scope kind.  But then we need to adjust the prohibition on
    placeholders declaring implicit template parameters.

            PR c++/101677

    gcc/cp/ChangeLog:

            * name-lookup.h (struct cp_binding_level): Add requires_expression
            bit-field.
            * parser.cc (cp_parser_requires_expression): Set it.
            (synthesize_implicit_template_parm): Check it.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-pr67178.C: Adjust error.
            * g++.dg/cpp2a/concepts-requires28.C: New test.

[Bug c++/101677] [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:556d061e62ea863c7f99129219ca69bf0792c7f1

commit r11-9828-g556d061e62ea863c7f99129219ca69bf0792c7f1
Author: Jason Merrill <jason@redhat.com>
Date:   Sun Mar 27 22:31:51 2022 -0400

    c++: elaborated-type-spec in requires-expr [PR101677]

    We were failing to declare class S in the global namespace because we were
    treating the requires-expression parameter scope as a normal block scope,
so
    the implicit declaration went there.

    It seems to me that the requires parameter scope is more like a function
    parameter scope (not least in the use of the word "parameter"), so let's
    change the scope kind.  But then we need to adjust the prohibition on
    placeholders declaring implicit template parameters.

            PR c++/101677

    gcc/cp/ChangeLog:

            * name-lookup.h (struct cp_binding_level): Add requires_expression
            bit-field.
            * parser.c (cp_parser_requires_expression): Set it.
            (synthesize_implicit_template_parm): Check it.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-pr67178.C: Adjust error.
            * g++.dg/cpp2a/concepts-requires28.C: New test.

[Bug c++/101677] [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for 11.3/12.

[Bug c++/101677] [11 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arthur.j.odwyer at gmail dot com

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 97988 has been marked as a duplicate of this bug. ***