Like this?
// Parse a requires clause.
//
// requires-clause:
// 'requires' logical-or-expression
//
// The required logical-or-expression must be a constant expression.
static tree
cp_parser_requires_clause (cp_parser *parser)
{
// Parse the constant expression.
tree expr =
cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR, NULL);
if (!require_potential_rvalue_constant_expression (expr))
return error_mark_node;
return expr;
}
Okay to commit?
On Sat, Jun 22, 2013 at 9:41 AM, Gabriel Dos Reis <g...@axiomatics.org> wrote:
> Andrew Sutton <andrew.n.sut...@gmail.com> writes:
>
> | > | + // Concept extensions
> | > | + case RID_REQUIRES:
> | > | + return cp_parser_requires_expression (parser);
> | > | +
> | >
> | > I think you meant here "nested requirements", not "extensions" as in
> | > "GNU extensions" or "vendor lock-ins". We should continue with "nested
> | > requirements" then.
> |
> | This denotes a primary expression, not a nested requirement. I was
> | trying to subset the requirement like the "Objective-C++ expressions"
> | comment just below it.
> |
> | I changed the comment to just "C++ concepts". We may get other primary
> | expressions related to concepts, although I don't have any planned.
>
> OK.
>
> | > | +static inline tree
> | > | +cp_parser_requires_clause (cp_parser *parser)
> | > | +{
> | > | + // Parse the constant expression.
> | > | + tree expr =
> | > | + cp_parser_binary_expression (parser, false, false,
> PREC_NOT_OPERATOR, NULL);
> | > | + if (!require_potential_rvalue_constant_expression (expr))
> | > | + return error_mark_node;
> | > | + return expr;
> | >
> | > The grammar says "constant-expression". You should use
> | > cp_parser_constant_expression.
> |
> | When we started talking about requirements, we didn't want the full
> | breadth of an expression, so I limited it to a logical-or-expression
> | that is also a constant expression. Commas, assignments, and
> | conditions at the top-level seemed counter-intuitive.
>
> I guess what I was saying earlier was that the comment preceding the
> function said "constant-expression", and we want the code to match that.
>
> I am not sure it is less counter-intuitive to allow non-toplevel comma
> constant expression but disallow toplevel ones; they will all end up
> being logical literal terms anyway. We shouldn't worry about
> assignments, for we are enforcing the semantics constraints of constant
> expressions.
>
> | Do we want to allow any constant expression, or should we just change
> | the docs to logical-or-expression that is also a constant expression?
>
> Yes; and change the comments to say the grammar term is
> logical-or-expression, with additional semantics constraint that they
> must be constant expressions.
>
> -- Gaby
--
Andrew Sutton
andrew.n.sut...@gmail.com
