On 06/25/2013 09:27 AM, Andrew Sutton wrote:
+/* The REQ expressions are unary expressions that specific inididual
"specify"?
+/* A unary expression representing a requirement for an expression that
+ may be evaluated at compile time. */
The word "may" is ambiguous and should be avoided in favor of "might" or
"can".
Judging from the implementation, it seems that this relies on the notion
of "potentially-constant expression" which is no longer part of the
standard; that notion should only be used for diagnostics that are not
required, not for things that participate in the type system.
I think it would be better to have a requirement that a particular
expression instantiate into an actual constant expression.
+ // Note that vlaidtype requirements are implicit.
"validtype"
+ // Pretty print the '-> type-id' part of the expression.
+ // Note that treq will contain a TRAIT_EXPR.
+ tree type = TRAIT_EXPR_TYPE2 (TREE_VALUE (treq));
This seems to assume that there is a result-type-requirement.
+// Returns true if type1 can be implicitly converted to type2.
+static inline bool
+convertible_to_p (tree type1, tree type2)
+{
+ // Build a "fake" conversion expression to force the lookup of user
+ // defined conversion sequences.
+ tree expr = build_min (CAST_EXPR, type1);
+ return can_convert_arg (type2, type1, expr, LOOKUP_IMPLICIT, tf_none);
+}
Can't you use can_convert instead of a new function?
+ // Modify the declared parameters by removing their context (so they
+ // don't refer to the enclosing scope), and making the constant (so
+ // we can actually check constexpr properties).
"marking them"?
Does this actually work?
+build_check_expr (tree_code c, tree t)
+{
+ tree r = build_min (c, boolean_type_node, t);
+ TREE_SIDE_EFFECTS (r) = false;
+ TREE_READONLY (r) = true;
+ TREE_CONSTANT (r) = true;
TREE_READONLY isn't meaningful on rvalue expressions.
+ return truth_node (expr && EXPR_P (expr) && TYPE_P (TREE_TYPE (expr)));
This excludes expressions that just name a declaration. I would expect
'expr && expr != error_mark_node' to do the right thing; was the
TREE_TYPE check motivated by anything in particular?
Jason
