From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C895F3857C5E; Mon, 5 Apr 2021 19:49:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C895F3857C5E From: "the_gamester28 at msn dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern Date: Mon, 05 Apr 2021 19:49:29 +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: 11.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: the_gamester28 at msn dot com X-Bugzilla-Status: SUSPENDED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 19:49:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99599 --- Comment #4 from the_gamester28 at msn dot com --- (In reply to Jason Merrill from comment #2) > (In reply to the_gamester28 from comment #0) > > It seems that the template requirements of invoke_tag(bar_tag, int) are > > considered while evaluating line marked "here". Requirements of irrelev= ant > > overloads should not be considered, as it can potentially lead to false= ly > > reporting a cyclic dependency. >=20 > This is as specified by http://wg21.link/cwg2369 >=20 > I think it would be reasonable to allow a compiler to accept the testcase > under a generalization of 13.9.1/9: "If the function selected by overload > resolution (12.4) can be determined without instantiating a class template > definition, it is unspecified whether that instantiation actually takes > place." >=20 > But that does not require a compiler to accept it. >=20 > It might make sense to check non-dependent conversions that don't require > template instantiation, then constraints, then non-dependent conversions > that do require template instantiation. But that's a matter for the > committee; G++ is conforming to the current working paper. Perhaps I was too quick to assert what I expected the implementation detail= s to be. The fooable concept should be satisfied for any (T it) for which invoke_tag(foo_tag{}, it) is unambiguously applicable. The fact that the invoke_tag(bar_tag, T) overload exists should not preclude that. It is not = up to me how the compiler comes to that end, but that is the desired outcome. It is still possible to ban recursive constraints, keep the new GCC 11 implementation, and still have this particular code compile with a small alteration in behaviour: The compiler does not immediately bail out as soon as it sees recursion in = an overload candidate, but marks that particular candidate as invalid. If there are no applicable overloads (because they are all recursive, or th= ey are invalid for some other reason), then the compiler can reject the code a= nd list all of the reasons why all of the candidates are invalid. In this case, it would mark invoke_tag(bar_tag, int) as not-applicable due = to the constraint recursion, and carry on checking the rest of the overloads f= or applicability, until it is sure that there is one and only one applicable overload: invoke_tag(foo_tag, int).=