diff mbox

[C++] PR 51225

Message ID 4F117518.6090700@oracle.com
State New
Headers show

Commit Message

Paolo Carlini Jan. 14, 2012, 12:29 p.m. UTC 
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:


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.

Comments

Jason Merrill Jan. 17, 2012, 4:04 a.m. UTC | #1 
So, the issue here is that fold_non_dependent_expr_sfinae checks 
potential_constant_expression, and doesn't fold anything which isn't one.

One approach would be to only guard cxx_constant_value with 
require_potential_constant_expression within a template.

Another approach would be to check potential_constant_expression at the 
same place that we check type/value_dependent_expression_p, i.e. in 
cp_finish_decl and convert_template_argument.

Jason
diff mbox

Patch

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),