[PATCH] c++: Some cp-tree.def comment fixes

[Marek Polacek]

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