Re: [Patch][v2] C++: Handle OpenMP/OpenACC array sections [: / :] with C++26

On 8/5/26 12:50 PM, Tobias Burnus wrote:
> Jason Merrill wrote:
>> On 7/31/26 7:40 AM, Tobias Burnus wrote:
>> In unchanged code:
>>
>>>   if (for_offsetof)
>>>     index = cp_parser_constant_expression (parser);
>>>   else if (!parser->omp_array_section_p
>>>            || cp_lexer_next_token_is_not (parser->lexer, CPP_COLON))
>> Don't you need to check CPP_CLOSE_SPLICE here?
> 
> Yes. — I thought I had all possible variants in as testcase, but I 
> missed that one. I have now added many more testcases – including 
> invalid ones. (Esp. '[ : : ]', i.e. a tailing ':' which becomes only 
> valid for strided arrays; those are only valid in 'target update' and 
> strides are still unsupported on mainline.)
> 
> With the additional tests, one runs also in some other issues you raised.
> 
>>> @@ -9469,6 +9502,9 @@ cp_parser_postfix_open_square_expression 
>>> (cp_parser *parser,
>>>        cp_parser_skip_to_closing_square_bracket (parser);
>> Not necessary, but I wonder if we want to do anything 
>> to ...skip_to_...bracket to handle CPP_CLOSE_SPLICE?
> 
> Good question. The problem is that there can be both split specifier and
> array section use like in '[ [: ... :] ]'. Depending where one is with
> the parser, one might want to handle ':]' on equal footing or not – And
> if ... fails, do we want to skip to the outer ']' or to the inner ':]'?
> 
> I have now implemented a variant, which hopefully more often makes
> sense than not.

Please also add a comment about the rationale there.  LGTM with that 
addition.

>>> @@ -41882,25 +41919,34 @@ cp_parser_omp_var_list_no_open (cp_parser 
>>> *parser, enum omp_clause_code kind,>            if (!colon)
>>>              parser->colon_corrects_to_scope_p
>>>                = saved_colon_corrects_to_scope_p;
>> Not relevant to this patch, but I wonder why most of the handling of 
>> colon_corrects_to_scope_p in this function is conditional on whether 
>> the caller passed a pointer to the 'colon' parameter?
> 
> I think it is fine at the end of the function, but, here,
> it seems to make more sense to reset it unconditionally as
> it is also set unconditionally.
> 
> Thus, I have done so.
> 
> Thanks for the review! Any comments to the revised version?