Re: [PATCH] c++: decltype of (non-captured variable) [PR83167]

[Jason Merrill <jason@redhat.com>]

On 12/1/23 12:32, Patrick Palka wrote:
> On Tue, 14 Nov 2023, Jason Merrill wrote:
> 
>> On 11/14/23 11:10, Patrick Palka wrote:
>>> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
>>> trunk?
>>>
>>> -- >8 --
>>>
>>> For decltype((x)) within a lambda where x is not captured, we dubiously
>>> require that the lambda has a capture default, unlike for decltype(x).
>>> This patch fixes this inconsistency; I couldn't find a justification for
>>> it in the standard.
>>
>> The relevant passage seems to be
>>
>> https://eel.is/c++draft/expr.prim#id.unqual-3
>>
>> "If naming the entity from outside of an unevaluated operand within S would
>> refer to an entity captured by copy in some intervening lambda-expression,
>> then let E be the innermost such lambda-expression.
>>
>> If there is such a lambda-expression and if P is in E's function parameter
>> scope but not its parameter-declaration-clause, then the type of the
>> expression is the type of a class member access expression ([expr.ref]) naming
>> the non-static data member that would be declared for such a capture in the
>> object parameter ([dcl.fct]) of the function call operator of E."
>>
>> In this case I guess there is no such lambda-expression because naming x won't
>> refer to a capture by copy if the lambda doesn't capture anything, so we
>> ignore the lambda.
>>
>> Maybe refer to that in a comment?  OK with that change.
>>
>> I'm surprised that it refers specifically to capture by copy, but I guess a
>> capture by reference should have the same decltype as the captured variable?
> 
> Ah, seems like it.  So maybe we should get rid of the redundant
> by-reference capture-default handling, to more closely mirror the
> standard?
> 
> Also now that r14-6026-g73e2bdbf9bed48 made capture_decltype return
> NULL_TREE to mean the capture is dependent, it seems we should just
> inline capture_decltype into finish_decltype_type rather than
> introducing another special return value to mean "fall back to ordinary
> handling".
> 
> How does the following look?  Bootstrapped and regtested on
> x86_64-pc-linux-gnu.
> 
> -- >8 --
> 
> 	PR c++/83167
> 
> gcc/cp/ChangeLog:
> 
> 	* semantics.cc (capture_decltype): Inline into its only caller ...
> 	(finish_decltype_type): ... here.  Update nearby comment to refer
> 	to recent standard.  Restrict uncaptured variable handling to just
> 	lambdas with a by-copy capture-default.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/cpp0x/lambda/lambda-decltype4.C: New test.
> ---
>   gcc/cp/semantics.cc                           | 107 +++++++-----------
>   .../g++.dg/cpp0x/lambda/lambda-decltype4.C    |  15 +++
>   2 files changed, 55 insertions(+), 67 deletions(-)
>   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype4.C
> 
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index fbbc18336a0..fb4c3992e34 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -53,7 +53,6 @@ along with GCC; see the file COPYING3.  If not see
>   
>   static tree maybe_convert_cond (tree);
>   static tree finalize_nrv_r (tree *, int *, void *);
> -static tree capture_decltype (tree);
>   
>   /* Used for OpenMP non-static data member privatization.  */
>   
> @@ -11856,21 +11855,48 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p,
>       }
>     else
>       {
> -      /* Within a lambda-expression:
> -
> -	 Every occurrence of decltype((x)) where x is a possibly
> -	 parenthesized id-expression that names an entity of
> -	 automatic storage duration is treated as if x were
> -	 transformed into an access to a corresponding data member
> -	 of the closure type that would have been declared if x
> -	 were a use of the denoted entity.  */
>         if (outer_automatic_var_p (STRIP_REFERENCE_REF (expr))
>   	  && current_function_decl
>   	  && LAMBDA_FUNCTION_P (current_function_decl))
>   	{
> -	  type = capture_decltype (STRIP_REFERENCE_REF (expr));
> -	  if (!type)
> -	    goto dependent;
> +	  /* [expr.prim.id.unqual]/3: If naming the entity from outside of an
> +	     unevaluated operand within S would refer to an entity captured by
> +	     copy in some intervening lambda-expression, then let E be the
> +	     innermost such lambda-expression.
> +
> +	     If there is such a lambda-expression and if P is in E's function
> +	     parameter scope but not its parameter-declaration-clause, then the
> +	     type of the expression is the type of a class member access
> +	     expression naming the non-static data member that would be declared
> +	     for such a capture in the object parameter of the function call
> +	     operator of E."  */

Hmm, looks like this code is only checking the innermost lambda, it 
needs to check all containing lambdas for one that would capture it by copy.

> +	  tree decl = STRIP_REFERENCE_REF (expr);
> +	  tree lam = CLASSTYPE_LAMBDA_EXPR (DECL_CONTEXT (current_function_decl));
> +	  tree cap = lookup_name (DECL_NAME (decl), LOOK_where::BLOCK,
> +				  LOOK_want::HIDDEN_LAMBDA);
> +
> +	  if (cap && is_capture_proxy (cap))
> +	    type = TREE_TYPE (cap);
> +	  else if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lam) == CPLD_COPY)
> +	    {
> +	      type = TREE_TYPE (decl);
> +	      if (TYPE_REF_P (type)
> +		  && TREE_CODE (TREE_TYPE (type)) != FUNCTION_TYPE)
> +		type = TREE_TYPE (type);
> +	    }
> +
> +	  if (type && !TYPE_REF_P (type))
> +	    {
> +	      tree obtype = TREE_TYPE (DECL_ARGUMENTS (current_function_decl));
> +	      if (WILDCARD_TYPE_P (non_reference (obtype)))
> +		/* We don't know what the eventual obtype quals will be.  */
> +		goto dependent;
> +	      int quals = cp_type_quals (type);
> +	      if (INDIRECT_TYPE_P (obtype))
> +		quals |= cp_type_quals (TREE_TYPE (obtype));
> 
> Shouldn't we propagate cv-quals of a by-value object parameter as well?

Ah, I think you're right.

Jason