From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 432943858402; Tue, 21 Sep 2021 14:49:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 432943858402
From: "ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/102419] [11/12 Regression][concepts] [regression]
 return-type-requirement of "Y<typename T::type>" does not check that T::type
 actually exists
Date: Tue, 21 Sep 2021 14:49:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppalka at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-102419-4-42IilYbXAu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102419-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102419-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Sep 2021 14:49:58 -0000

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The behavior of this testcase was changed with r11-7454 (the testcase
concepts-return-req2.C added there is essentially identical to this one).=20
Before this commit, we'd substitute template arguments into the
return-type-requirement before checking satisfaction, and now we substitute
template arguments as part of satisfaction (into the normal form of the
constraint, which is just 'true (with an empty parameter mapping)'), which
explains the behavior change.

AFAICT, the standard is inconsistent about whether a separate substitution
should be performed here.  On the one hand, [expr.prim.req.compound] says

  - Substitution of template arguments (if any) into the
return-type-requirement is performed.

which suggests a separate substitution should be performed.  On the other h=
and,
the example in that same section says a compound-requirement is equivalent =
to a
simple-requirement & nested-requirement:

  Given concepts C and D,

    requires {
      { E1 } -> C;
      { E2 } -> D<A1, =E2=8B=AF, An>;
    };

  is equivalent to

  requires {
    E1; requires C<decltype((E1))>;
    E2; requires D<decltype((E2)), A1, =E2=8B=AF, An>;
  };

and we certainly shouldn't be doing a separate substitution when checking a
nested-requirement.  IIUC, GCC's behavior is consistent with the example.

Generally GCC tries to avoid doing a separate substitution into a constraint
whenever we can get away with it and instead perform the substitution as pa=
rt
of satisfaction.  This e.g. also occurs for the type-constraint of a=20
placeholder type:

  template<class, class> concept Y =3D true;
  template<class T> void f() {
    Y<typename T::type> auto y =3D 0;
  }
  template void f<int>(); // GCC accepts, Clang/MSVC reject=