Hi,
On 01/13/2012 03:57 PM, Paolo Carlini wrote:
Anyway, the reason we are not tsubst-ing such trees - eg, a CAST_EXPR on
a single element TREE_LIST as argument, with error_mark_node as value -
is that potential_constant_expression is false in
fold_non_dependent_expr_sfinae, thus tsubst_copy_and_build is not called
at all.
We also shouldn't call cxx_eval_constant_expression if
potential_constant_expression is false.
Ok. At this point I'm not sure anymore whether this mild error recovery
issue is worth more of your (and my ;) time, but anyway, I tell you what
I did in the meanwhile.
This kind of change:
Index: pt.c
===================================================================
--- pt.c (revision 183178)
+++ pt.c (working copy)
@@ -5807,6 +5807,8 @@ convert_nontype_argument (tree type, tree expr, ts
if (complain & tf_error)
{
int errs = errorcount, warns = warningcount;
+ if (!require_potential_constant_expression (expr))
+ return NULL_TREE;
expr = cxx_constant_value (expr);
if (errorcount > errs || warningcount > warns)
inform (EXPR_LOC_OR_HERE (expr),
fixes the problem with the first snippet in PR51225, which has strictly
to do with nontype template parameters.
But then we have the second kind of snippet, which is about the
cxx_constant_value call part of store_init_value. In this case trying to
avoid calling cxx_constant_value when there are no chances the value is
constant causes regressions, because normally we produce a lot of
diagnostics as part of cxx_eval_constant_expression which we don't
produce anymore: for example, for constexpr-diag1.C, the diagnostics
produced by cxx_eval_call_expression disappears. Thus, I'm not sure we
could do. I don't think we can now attempt to either take diagnostics
out of cxx_eval_constant_expression or beef up the diagnostics in
potential_constant_expression?!? Maybe we should somehow figure out
whether in the expression there are error_mark_node embedded and only in
that conservative case completely avoid calling
cxx_eval_constant_expression, but at present
potential_constant_expression just returns false in that case doesn't
tell it apart from the other cases of non-potential.
Thanks,
Paolo.