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 <ja...@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
