Re: [C++ Patch] PR 51225

[Paolo Carlini <paolo dot carlini at oracle dot com>]

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.