Updated with corrections for previous comments. New patch attached, but the Changelog is essentially the same.
>> +/* A unary expression representing a requirement for an expression that
>> + can be evaluated at compile time. */
>
> 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.
I've disabled this feature for the time being with a "sorry" error.
I'll revisit the problem when I plug in the tsbust rules.
>> +// 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?
Whatever problems I ran into previously don't seem to bother me now. I
removed this function in favor of using can_convert().
Unfortunately, the behavior differs from the test suite for
std::is_convertible. In particular, this fails:
static_assert(__is_convertible_to(int(int), int(&)(int)), "");
whereas this succeeds )
static_assert(is_convertible<int(int), int(&)(int)>::value, "");
Line 61 of the is_convertible test. I haven't tried fixing this one...
>> + // 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?
Sure did. This may not be relevant after the forthcoming changes to
how the constexpr test is actually implemented.
> 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?
In the formal model I'm designing, __is_valid_expr(e) evaluates to
true when e has a type. Although, if I'm instantiating a non-dependent
expression, I'll probably get an error_mark_node if the expression
can't be typed. Right?
Andrew
reqexpr-3.patch
Description: Binary data
