c++: Some cp-tree.def comment fixes

  Hi!

While reading the fold expression and concept tree comments, I found
various spots referring to non-existent macros etc.

The following patch attempts to sync that with what is actually implemented.

Ok for trunk?

2024-07-22  Jakub Jelinek  <jakub@redhat.com>

	* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
	of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment.  Comment
	formatting fixes.
	(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
	and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
	Comment formatting fixes.
	(CONJ_CONSTR): Remove comment about third operand.  Use CONSTR_INFO
	instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
	(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
	CHECK_CONSTR_ARGUMENTS.


	Jakub
  

On Mon, Jul 22, 2024 at 05:32:17PM +0200, Jakub Jelinek wrote:
> Hi!
> 
> While reading the fold expression and concept tree comments, I found
> various spots referring to non-existent macros etc.
> 
> The following patch attempts to sync that with what is actually implemented.
> 
> Ok for trunk?

LGTM.
 
> 2024-07-22  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
> 	of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment.  Comment
> 	formatting fixes.
> 	(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
> 	and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
> 	Comment formatting fixes.
> 	(CONJ_CONSTR): Remove comment about third operand.  Use CONSTR_INFO
> 	instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
> 	(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
> 	CHECK_CONSTR_ARGUMENTS.
> 
> --- gcc/cp/cp-tree.def.jj	2024-04-09 09:29:04.709521893 +0200
> +++ gcc/cp/cp-tree.def	2024-07-22 17:26:32.053101302 +0200
> @@ -412,17 +412,17 @@ DEFTREECODE (ARGUMENT_PACK_SELECT, "argu
>  /* Fold expressions allow the expansion of a template argument pack
>     over a binary operator.
>  
> -   FOLD_EXPR_MOD_P is true when the fold operation is a compound assignment
> +   FOLD_EXPR_MODIFY_P is true when the fold operation is a compound assignment
>     operator.
>  
>     FOLD_EXPR_OP is an INTEGER_CST storing the tree code for the folded
> -   expression. Note that when FOLDEXPR_MOD_P is true, the operator is
> +   expression.  Note that when FOLD_EXPR_MODIFY_P is true, the operator is
>     a compound assignment operator for that kind of expression.
>  
>     FOLD_EXPR_PACK is an expression containing an unexpanded parameter pack;
>     when expanded, each term becomes an argument of the folded expression.
>  
> -   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument. */
> +   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument.  */
>  DEFTREECODE (UNARY_LEFT_FOLD_EXPR, "unary_left_fold_expr", tcc_expression, 2)
>  DEFTREECODE (UNARY_RIGHT_FOLD_EXPR, "unary_right_fold_expr", tcc_expression, 2)
>  DEFTREECODE (BINARY_LEFT_FOLD_EXPR, "binary_left_fold_expr", tcc_expression, 3)
> @@ -518,24 +518,23 @@ DEFTREECODE (NESTED_REQ, "nested_req", t
>  
>  /* Constraints are modeled as kinds of expressions.
>     The operands of a constraint can be either types or expressions.
> -   Unlike expressions, constraints do not have a type. */
> +   Unlike expressions, constraints do not have a type.  */
>  
>  /* An atomic constraint evaluates an expression E. The operand of the
> -   constraint is its parameter mapping. The actual expression is stored
> +   constraint is its parameter mapping.  The actual expression is stored
>     in the context.
>  
> -   ATOMIC_CONSTR_INFO provides source info to support diagnostics.
> +   CONSTR_INFO provides source info to support diagnostics.
>     ATOMIC_CONSTR_EXPR has the expression to be evaluated.
> -   ATOMIC_CONSTR_PARMS is the parameter mapping for the atomic constraint
> +   ATOMIC_CONSTR_MAP is the parameter mapping for the atomic constraint
>     and is stored in the type field.  */
>  DEFTREECODE (ATOMIC_CONSTR, "atomic_constr", tcc_expression, 1)
>  
>  /* The conjunction and disjunction of two constraints, respectively.
> -   Operands are accessed using TREE_OPERAND. The third operand provides
> -   source info for diagnostics.
> +   Operands are accessed using TREE_OPERAND.
>  
> -   CONJ_CONSTR_INFO and DISJ_CONSTR_INFO provide access to the source
> -   information of constraints, which is stored in the TREE_TYPE.  */
> +   CONSTR_INFO provides access to the source information of constraints,
> +   which is stored in the TREE_TYPE.  */
>  DEFTREECODE (CONJ_CONSTR, "conj_constr", tcc_expression, 2)
>  DEFTREECODE (DISJ_CONSTR, "disj_constr", tcc_expression, 2)
>  
> @@ -544,7 +543,7 @@ DEFTREECODE (DISJ_CONSTR, "disj_constr",
>     and a sequence of template arguments.
>  
>     CHECK_CONSTR_CONCEPT has the concept definition
> -   CHECK_CONSTR_ARGUMENTS are the template arguments */
> +   CHECK_CONSTR_ARGS are the template arguments.   */
>  DEFTREECODE (CHECK_CONSTR, "check_constr", tcc_expression, 2)
>  
>  /* The co_await expression is used to support coroutines.
> 
> 	Jakub
> 

Marek
  

On Mon, 22 Jul 2024, Jakub Jelinek wrote:

> Hi!
> 
> While reading the fold expression and concept tree comments, I found
> various spots referring to non-existent macros etc.
> 
> The following patch attempts to sync that with what is actually implemented.
> 
> Ok for trunk?
> 
> 2024-07-22  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
> 	of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment.  Comment
> 	formatting fixes.
> 	(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
> 	and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
> 	Comment formatting fixes.
> 	(CONJ_CONSTR): Remove comment about third operand.  Use CONSTR_INFO
> 	instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
> 	(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
> 	CHECK_CONSTR_ARGUMENTS.
> 
> --- gcc/cp/cp-tree.def.jj	2024-04-09 09:29:04.709521893 +0200
> +++ gcc/cp/cp-tree.def	2024-07-22 17:26:32.053101302 +0200
> @@ -412,17 +412,17 @@ DEFTREECODE (ARGUMENT_PACK_SELECT, "argu
>  /* Fold expressions allow the expansion of a template argument pack
>     over a binary operator.
>  
> -   FOLD_EXPR_MOD_P is true when the fold operation is a compound assignment
> +   FOLD_EXPR_MODIFY_P is true when the fold operation is a compound assignment
>     operator.
>  
>     FOLD_EXPR_OP is an INTEGER_CST storing the tree code for the folded
> -   expression. Note that when FOLDEXPR_MOD_P is true, the operator is
> +   expression.  Note that when FOLD_EXPR_MODIFY_P is true, the operator is
>     a compound assignment operator for that kind of expression.
>  
>     FOLD_EXPR_PACK is an expression containing an unexpanded parameter pack;
>     when expanded, each term becomes an argument of the folded expression.
>  
> -   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument. */
> +   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument.  */
>  DEFTREECODE (UNARY_LEFT_FOLD_EXPR, "unary_left_fold_expr", tcc_expression, 2)
>  DEFTREECODE (UNARY_RIGHT_FOLD_EXPR, "unary_right_fold_expr", tcc_expression, 2)
>  DEFTREECODE (BINARY_LEFT_FOLD_EXPR, "binary_left_fold_expr", tcc_expression, 3)
> @@ -518,24 +518,23 @@ DEFTREECODE (NESTED_REQ, "nested_req", t
>  
>  /* Constraints are modeled as kinds of expressions.
>     The operands of a constraint can be either types or expressions.
> -   Unlike expressions, constraints do not have a type. */
> +   Unlike expressions, constraints do not have a type.  */
>  
>  /* An atomic constraint evaluates an expression E. The operand of the
> -   constraint is its parameter mapping. The actual expression is stored
> +   constraint is its parameter mapping.  The actual expression is stored
>     in the context.
>  
> -   ATOMIC_CONSTR_INFO provides source info to support diagnostics.
> +   CONSTR_INFO provides source info to support diagnostics.
>     ATOMIC_CONSTR_EXPR has the expression to be evaluated.
> -   ATOMIC_CONSTR_PARMS is the parameter mapping for the atomic constraint
> +   ATOMIC_CONSTR_MAP is the parameter mapping for the atomic constraint
>     and is stored in the type field.  */
>  DEFTREECODE (ATOMIC_CONSTR, "atomic_constr", tcc_expression, 1)
>  
>  /* The conjunction and disjunction of two constraints, respectively.
> -   Operands are accessed using TREE_OPERAND. The third operand provides
> -   source info for diagnostics.
> +   Operands are accessed using TREE_OPERAND.
>  
> -   CONJ_CONSTR_INFO and DISJ_CONSTR_INFO provide access to the source
> -   information of constraints, which is stored in the TREE_TYPE.  */
> +   CONSTR_INFO provides access to the source information of constraints,
> +   which is stored in the TREE_TYPE.  */
>  DEFTREECODE (CONJ_CONSTR, "conj_constr", tcc_expression, 2)
>  DEFTREECODE (DISJ_CONSTR, "disj_constr", tcc_expression, 2)
>  
> @@ -544,7 +543,7 @@ DEFTREECODE (DISJ_CONSTR, "disj_constr",
>     and a sequence of template arguments.
>  
>     CHECK_CONSTR_CONCEPT has the concept definition
> -   CHECK_CONSTR_ARGUMENTS are the template arguments */
> +   CHECK_CONSTR_ARGS are the template arguments.   */
>  DEFTREECODE (CHECK_CONSTR, "check_constr", tcc_expression, 2)

FWIW this tree code seems to be a vestige of the initial Concepts TS
implementation and is effectively unused, we can remove it outright.

>  
>  /* The co_await expression is used to support coroutines.
> 
> 	Jakub
> 
>
  

On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote:
> On Mon, 22 Jul 2024, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > While reading the fold expression and concept tree comments, I found
> > various spots referring to non-existent macros etc.
> > 
> > The following patch attempts to sync that with what is actually implemented.
> > 
> > Ok for trunk?
> > 
> > 2024-07-22  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
> > 	of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment.  Comment
> > 	formatting fixes.
> > 	(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
> > 	and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
> > 	Comment formatting fixes.
> > 	(CONJ_CONSTR): Remove comment about third operand.  Use CONSTR_INFO
> > 	instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
> > 	(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
> > 	CHECK_CONSTR_ARGUMENTS.
> > 
> > --- gcc/cp/cp-tree.def.jj	2024-04-09 09:29:04.709521893 +0200
> > +++ gcc/cp/cp-tree.def	2024-07-22 17:26:32.053101302 +0200
> > @@ -412,17 +412,17 @@ DEFTREECODE (ARGUMENT_PACK_SELECT, "argu
> >  /* Fold expressions allow the expansion of a template argument pack
> >     over a binary operator.
> >  
> > -   FOLD_EXPR_MOD_P is true when the fold operation is a compound assignment
> > +   FOLD_EXPR_MODIFY_P is true when the fold operation is a compound assignment
> >     operator.
> >  
> >     FOLD_EXPR_OP is an INTEGER_CST storing the tree code for the folded
> > -   expression. Note that when FOLDEXPR_MOD_P is true, the operator is
> > +   expression.  Note that when FOLD_EXPR_MODIFY_P is true, the operator is
> >     a compound assignment operator for that kind of expression.
> >  
> >     FOLD_EXPR_PACK is an expression containing an unexpanded parameter pack;
> >     when expanded, each term becomes an argument of the folded expression.
> >  
> > -   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument. */
> > +   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument.  */
> >  DEFTREECODE (UNARY_LEFT_FOLD_EXPR, "unary_left_fold_expr", tcc_expression, 2)
> >  DEFTREECODE (UNARY_RIGHT_FOLD_EXPR, "unary_right_fold_expr", tcc_expression, 2)
> >  DEFTREECODE (BINARY_LEFT_FOLD_EXPR, "binary_left_fold_expr", tcc_expression, 3)
> > @@ -518,24 +518,23 @@ DEFTREECODE (NESTED_REQ, "nested_req", t
> >  
> >  /* Constraints are modeled as kinds of expressions.
> >     The operands of a constraint can be either types or expressions.
> > -   Unlike expressions, constraints do not have a type. */
> > +   Unlike expressions, constraints do not have a type.  */
> >  
> >  /* An atomic constraint evaluates an expression E. The operand of the
> > -   constraint is its parameter mapping. The actual expression is stored
> > +   constraint is its parameter mapping.  The actual expression is stored
> >     in the context.
> >  
> > -   ATOMIC_CONSTR_INFO provides source info to support diagnostics.
> > +   CONSTR_INFO provides source info to support diagnostics.
> >     ATOMIC_CONSTR_EXPR has the expression to be evaluated.
> > -   ATOMIC_CONSTR_PARMS is the parameter mapping for the atomic constraint
> > +   ATOMIC_CONSTR_MAP is the parameter mapping for the atomic constraint
> >     and is stored in the type field.  */
> >  DEFTREECODE (ATOMIC_CONSTR, "atomic_constr", tcc_expression, 1)
> >  
> >  /* The conjunction and disjunction of two constraints, respectively.
> > -   Operands are accessed using TREE_OPERAND. The third operand provides
> > -   source info for diagnostics.
> > +   Operands are accessed using TREE_OPERAND.
> >  
> > -   CONJ_CONSTR_INFO and DISJ_CONSTR_INFO provide access to the source
> > -   information of constraints, which is stored in the TREE_TYPE.  */
> > +   CONSTR_INFO provides access to the source information of constraints,
> > +   which is stored in the TREE_TYPE.  */
> >  DEFTREECODE (CONJ_CONSTR, "conj_constr", tcc_expression, 2)
> >  DEFTREECODE (DISJ_CONSTR, "disj_constr", tcc_expression, 2)
> >  
> > @@ -544,7 +543,7 @@ DEFTREECODE (DISJ_CONSTR, "disj_constr",
> >     and a sequence of template arguments.
> >  
> >     CHECK_CONSTR_CONCEPT has the concept definition
> > -   CHECK_CONSTR_ARGUMENTS are the template arguments */
> > +   CHECK_CONSTR_ARGS are the template arguments.   */
> >  DEFTREECODE (CHECK_CONSTR, "check_constr", tcc_expression, 2)
> 
> FWIW this tree code seems to be a vestige of the initial Concepts TS
> implementation and is effectively unused, we can remove it outright.

Thanks, that's on me, I suppose.  I have to get back to your comments in
<https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654396.html>:

FWIW I think we can also remove DECL_DECLARED_CONCEPT_P,
function_concept_p and variable_concept_p (and related code in
grokfndecl and grokvardecl probably).  And e.g. code in constraint.cc
that checks for FUNCTION_DECL, VAR_*, CALL_EXPR, OVERLOAD / OVL_* etc.

Marek
  

On 7/22/24 11:53 AM, Marek Polacek wrote:
> On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote:
>> On Mon, 22 Jul 2024, Jakub Jelinek wrote:
>>
>>> Hi!
>>>
>>> While reading the fold expression and concept tree comments, I found
>>> various spots referring to non-existent macros etc.
>>>
>>> The following patch attempts to sync that with what is actually implemented.
>>>
>>> Ok for trunk?
>>>
>>> 2024-07-22  Jakub Jelinek  <jakub@redhat.com>
>>>
>>> 	* cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use FOLD_EXPR_MODIFY_P instead
>>> 	of FOLD_EXPR_MOD_P or FOLDEXPR_MOD_P in the comment.  Comment
>>> 	formatting fixes.
>>> 	(ATOMIC_CONSTEXPR): Use CONSTR_INFO instead of ATOMIC_CONSTR_INFO
>>> 	and ATOMIC_CONSTR_MAP instead of ATOMIC_CONSTR_PARMS in the comment.
>>> 	Comment formatting fixes.
>>> 	(CONJ_CONSTR): Remove comment about third operand.  Use CONSTR_INFO
>>> 	instead of CONJ_CONSTR_INFO and DISJ_CONSTR_INFO.
>>> 	(CHECK_CONSTR): Use CHECK_CONSTR_ARGS instead of
>>> 	CHECK_CONSTR_ARGUMENTS.
>>>
>>> --- gcc/cp/cp-tree.def.jj	2024-04-09 09:29:04.709521893 +0200
>>> +++ gcc/cp/cp-tree.def	2024-07-22 17:26:32.053101302 +0200
>>> @@ -412,17 +412,17 @@ DEFTREECODE (ARGUMENT_PACK_SELECT, "argu
>>>   /* Fold expressions allow the expansion of a template argument pack
>>>      over a binary operator.
>>>   
>>> -   FOLD_EXPR_MOD_P is true when the fold operation is a compound assignment
>>> +   FOLD_EXPR_MODIFY_P is true when the fold operation is a compound assignment
>>>      operator.
>>>   
>>>      FOLD_EXPR_OP is an INTEGER_CST storing the tree code for the folded
>>> -   expression. Note that when FOLDEXPR_MOD_P is true, the operator is
>>> +   expression.  Note that when FOLD_EXPR_MODIFY_P is true, the operator is
>>>      a compound assignment operator for that kind of expression.
>>>   
>>>      FOLD_EXPR_PACK is an expression containing an unexpanded parameter pack;
>>>      when expanded, each term becomes an argument of the folded expression.
>>>   
>>> -   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument. */
>>> +   In a BINARY_FOLD_EXPRESSION, FOLD_EXPR_INIT is the non-pack argument.  */
>>>   DEFTREECODE (UNARY_LEFT_FOLD_EXPR, "unary_left_fold_expr", tcc_expression, 2)
>>>   DEFTREECODE (UNARY_RIGHT_FOLD_EXPR, "unary_right_fold_expr", tcc_expression, 2)
>>>   DEFTREECODE (BINARY_LEFT_FOLD_EXPR, "binary_left_fold_expr", tcc_expression, 3)
>>> @@ -518,24 +518,23 @@ DEFTREECODE (NESTED_REQ, "nested_req", t
>>>   
>>>   /* Constraints are modeled as kinds of expressions.
>>>      The operands of a constraint can be either types or expressions.
>>> -   Unlike expressions, constraints do not have a type. */
>>> +   Unlike expressions, constraints do not have a type.  */
>>>   
>>>   /* An atomic constraint evaluates an expression E. The operand of the
>>> -   constraint is its parameter mapping. The actual expression is stored
>>> +   constraint is its parameter mapping.  The actual expression is stored
>>>      in the context.
>>>   
>>> -   ATOMIC_CONSTR_INFO provides source info to support diagnostics.
>>> +   CONSTR_INFO provides source info to support diagnostics.
>>>      ATOMIC_CONSTR_EXPR has the expression to be evaluated.
>>> -   ATOMIC_CONSTR_PARMS is the parameter mapping for the atomic constraint
>>> +   ATOMIC_CONSTR_MAP is the parameter mapping for the atomic constraint
>>>      and is stored in the type field.  */
>>>   DEFTREECODE (ATOMIC_CONSTR, "atomic_constr", tcc_expression, 1)
>>>   
>>>   /* The conjunction and disjunction of two constraints, respectively.
>>> -   Operands are accessed using TREE_OPERAND. The third operand provides
>>> -   source info for diagnostics.
>>> +   Operands are accessed using TREE_OPERAND.
>>>   
>>> -   CONJ_CONSTR_INFO and DISJ_CONSTR_INFO provide access to the source
>>> -   information of constraints, which is stored in the TREE_TYPE.  */
>>> +   CONSTR_INFO provides access to the source information of constraints,
>>> +   which is stored in the TREE_TYPE.  */
>>>   DEFTREECODE (CONJ_CONSTR, "conj_constr", tcc_expression, 2)
>>>   DEFTREECODE (DISJ_CONSTR, "disj_constr", tcc_expression, 2)
>>>   
>>> @@ -544,7 +543,7 @@ DEFTREECODE (DISJ_CONSTR, "disj_constr",
>>>      and a sequence of template arguments.
>>>   
>>>      CHECK_CONSTR_CONCEPT has the concept definition
>>> -   CHECK_CONSTR_ARGUMENTS are the template arguments */
>>> +   CHECK_CONSTR_ARGS are the template arguments.   */
>>>   DEFTREECODE (CHECK_CONSTR, "check_constr", tcc_expression, 2)
>>
>> FWIW this tree code seems to be a vestige of the initial Concepts TS
>> implementation and is effectively unused, we can remove it outright.
> 
> Thanks, that's on me, I suppose.  I have to get back to your comments in
> <https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654396.html>:
> 
> FWIW I think we can also remove DECL_DECLARED_CONCEPT_P,
> function_concept_p and variable_concept_p (and related code in
> grokfndecl and grokvardecl probably).  And e.g. code in constraint.cc
> that checks for FUNCTION_DECL, VAR_*, CALL_EXPR, OVERLOAD / OVL_* etc.

Indeed.

In the meantime, Jakub's patch is OK.

Jason