From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AF4BA3851C3B; Fri, 5 Jun 2020 07:32:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF4BA3851C3B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1591342331; bh=Ybn6nluYiLm0WLGYl8HIL5IXK3ptWWW8d0ARlq5ozu8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F5RZEJx0gNLv71u+sn1RePYUjVG8HFk5t88T9Wi0cUPLs28ZyN6WTqzkNxIVx5MOP mASmQ7eToCYWxjyIIfm+e14hA+OMy4duJMjxCy6nnvZyFr8ZwJq2FLrpZitUiABC/4 iLKbVLYr8Tnqr+BUVhA07fEoZmz3SQhjBQivoKO4= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas Date: Fri, 05 Jun 2020 07:32:11 +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: 10.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: iains at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status everconfirmed assigned_to target_milestone cf_reconfirmed_on 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: Fri, 05 Jun 2020 07:32:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95540 Iain Sandoe changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gn= u.org Target Milestone|--- |10.2 Last reconfirmed| |2020-06-05 --- Comment #2 from Iain Sandoe --- There was a long discussion amongst the implementors at WG21 meeting in Pra= gue about what should be done for the closure object. The standard is really silent about coroutines and lambdas except by inference (and different implementors had made different inferences). The end result of the discussion is that we should treat it the same way a= s a class object (passing a reference to it to the traits, allocator lookup and promise parameter preview). current MSVC is the only implementation to have this complete, clang passes= the reference to the traits but not to the allocator / promise. GCC (current co= de) passes the closure pointer to all three. I posted a patch here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546299.html to bring GCC up to date with the agreed interpretation. After that, diagnostics will (as ever) be a QoI issue - as far as coroutines go, the implementation makes use of the same lookup facilities as the rest = of the C++ FE (so we should expect a consistent behaviour in terms of diagnostics). (libraries like cppcoro etc. make heavy use of coroutine lambdas, so they a= re certainly found to be viable).=