C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

Jason Merrill jason@redhat.com
Wed Mar 13 18:32:00 GMT 2019


On 3/12/19 5:42 PM, Marek Polacek wrote:
> On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote:
>> On 3/12/19 3:59 PM, Marek Polacek wrote:
>>> As Barry explained in the PR, lambda capture is one of
>>>
>>>     simple-capture ...[opt]
>>>     ...[opt] init-capture
>>>
>>> where init-capture requires an initializer.  Here we have
>>>
>>>     [...xs...]
>>>
>>> which is ill-formed as it's mingling both of these.
>>>
>>> Bootstrapped/regtested on x86_64-linux, ok for trunk?  Or should I defer to GCC
>>> 10?
>>>
>>> 2019-03-12  Marek Polacek  <polacek@redhat.com>
>>>
>>> 	PR c++/89686 - mixing init-capture and simple-capture in lambda.
>>> 	* parser.c (cp_parser_lambda_introducer): Give error when combining
>>> 	init-capture and simple-capture.
>>>
>>> 	* g++.dg/cpp2a/lambda-pack-init2.C: New test.
>>>
>>> diff --git gcc/cp/parser.c gcc/cp/parser.c
>>> index f95111169ed..d5d8f364752 100644
>>> --- gcc/cp/parser.c
>>> +++ gcc/cp/parser.c
>>> @@ -10721,6 +10721,15 @@ cp_parser_lambda_introducer (cp_parser* parser, tree lambda_expr)
>>>    	    {
>>>    	      cp_lexer_consume_token (parser->lexer);
>>>    	      capture_init_expr = make_pack_expansion (capture_init_expr);
>>> +	      if (init_pack_expansion)
>>> +		{
>>> +		  /* We'd already seen '...' so we were expecting an
>>> +		     init-capture.  But we just saw another '...' which
>>> +		     would imply a simple-capture.  */
>>> +		  error_at (capture_token->location,
>>> +			    "combining init-capture and simple-capture");
>>
>> That diagnostic seems a bit obscure, how about something like "too many
>> %<...%> in lambda capture"?
> 
> Yup, sounds better.
> 
>> Or perhaps check to see if there's an initializer after the ..., and
>> complain about the second ... if so, or the first ... if not.
> 
> I tried but we already give diagnostic for [...xs=xs...] or [...xs=...xs]
> and similar.

I was thinking about '...xs...=xs'.

> But let's at least use a proper location for the '...'.

This patch uses the location of ... after the identifier, but if there's 
no initializer, the ... before the identifier is the one we want to flag 
as invalid.

Jason



More information about the Gcc-patches mailing list