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

On 7/31/26 7:40 AM, Tobias Burnus wrote:
> OpenMP/OpenACC supports array sections of the form:
>     map ( var[start_idx : length] )
> where either can be left out (the start index is then 0
> and the length is taken from the type, if available.)
> 
> Hence, 'var[:n]', var[:], and 'var[3:]' might appear. While with
> a space before and after the ':', there is no issue, this changes
> when there is no space and C++26 is used. C++26 adds a splicer for
> reflections - and uses the for slicer [: and :]. And those get now
> lexed as CPP_OPEN_SPLICE and CPP_CLOSE_SPLICE; with C++23 or with
> space they are lexed as CPP_OPEN/CLOSE_SQUARE and CPP_COLON.
> 
> At least currently, there should be no ambiguity as the C++26
> use for splicers with reflections and OpenMP/OpenACC's use of
> array sections - as the usage is orthogonal. Therefore, this patch
> just handles the new tokens for the array sections.
> 
> Once committed, I intent to revert the following commit as follow up:
>    r16-5330-gedc821b60ce94b   OpenMP/OpenACC tests. vs C++26
> 
> Comments, remarks, concerns before I commit the patch?ß
> And before I revert r16-5330?
> 
> Tobias
> 
> PS: On the spec side, the issue has been discussed but no action taken;
> on the parser-side related (and tracked in the same spec issues) is
> 'var[::std::max(1,5):::std::min(1,5)]'.

> @@ -9425,12 +9452,18 @@ cp_parser_postfix_open_square_expression (cp_parser *parser,

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?

>  		"section");
>        index = error_mark_node;
>      }
> +
> +post_colon_parsing:

The goto to this label skips the greater_than_is_operator_p restore a 
few lines above.

>    if (parser->omp_array_section_p
> -      && cp_lexer_next_token_is (parser->lexer, CPP_COLON))
> +      && (open_splice
> +	  || cp_lexer_next_token_is (parser->lexer, CPP_COLON)
> +	  || cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SPLICE)))
>      {
> -      cp_lexer_consume_token (parser->lexer);
> +      if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))

This looks like it should be (!open_splice && to avoid consuming the 
second colon in [: : ]

> +	cp_lexer_consume_token (parser->lexer);
>        tree length = NULL_TREE;
> -      if (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_SQUARE))
> +      if (cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_SQUARE)
> +	  && cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_SPLICE))
>  	{
>  	  if (cxx_dialect >= cxx23)
>  	    {
> @@ -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?

> @@ -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?

> -		  if (cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))
> +		  if (!open_splice
> +		      && cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))

Line past 80 columns

> @@ -41919,7 +41967,8 @@ cp_parser_omp_var_list_no_open (cp_parser *parser, enum omp_clause_code kind,
>  			cp_parser_commit_to_tentative_parse (parser);
>  		      else
>  			array_section_p = true;
> -		      if (!cp_lexer_next_token_is (parser->lexer,
> +		      if (!close_splice &&

&& should be on next line

Jason