Iain discovered that a lambda fn's this pointer arg could be named
'this' and satisfy is_this_parameter, or be called __closure and not
satisfy it.
Turns out the parser explicitly zaps the name to be __closure, but
instantiation of a lambda fn doesn't. That's just confusing.
I tried not zapping the name in the parser, but that tripped over a
problem in constexpr.cc, which in pre-17 mode started complaining about
use of a this pointer in an constexpr fn. with the odd name, it never
recognized it as a this pointer. I could have updated that too, but the
smaller change seemed to be telling tsubst_function_decl to zap the name
too. (tsubst_function_decl has to treat a lambda;s this pointer
specially, it can't just send it to tsubst with the rest of the parms,
as that tickles an assert inside class instantiation.)
pushed to trunk
nathan
--
Nathan Sidwell
2020-05-05 Nathan Sidwell <nat...@acm.org>
PR c++/94807
* coroutines.cc (morph_fn_to_coro): Just check for
closure_identifier.
* pt.c (tsubst_function_decl): Update lambda fn's this_ptr name.
diff --git i/gcc/cp/coroutines.cc w/gcc/cp/coroutines.cc
index e90d3d5a3b3..246390ec0d1 100644
--- i/gcc/cp/coroutines.cc
+++ w/gcc/cp/coroutines.cc
@@ -3736,8 +3736,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer)
closure object is named 'this' instead of '__closure'. */
if (lambda_p)
{
- parm.lambda_cobj = parm.this_ptr
- || (DECL_NAME (arg) == closure_identifier);
+ parm.lambda_cobj = DECL_NAME (arg) == closure_identifier;
parm.this_ptr = false;
}
else
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 61cb75bf801..ff8391c2093 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -13821,6 +13821,7 @@ tsubst_function_decl (tree t, tree args, tsubst_flags_t complain,
if (closure)
{
tree tparm = build_this_parm (r, closure, type_memfn_quals (type));
+ DECL_NAME (tparm) = closure_identifier;
DECL_CHAIN (tparm) = parms;
parms = tparm;
}
