On Tue, Jan 30, 2018 at 3:18 PM, Marek Polacek <pola...@redhat.com> wrote:
> This testcase breaks since r256550 because we end up trying to build_address
> of
> a CONSTRUCTOR, but that doesn't work because we hit
> gcc_checking_assert (TREE_CODE (t) != CONSTRUCTOR);
>
> finish_static_assert gets {} as 'condition'.
Well, it gets X{}.
> In the testcase we have a
> user-defined conversion, so {} should be turned to false, via
> perform_implicit_conversion_flags -> ... -> build_user_type_conversion_1, but
> that crashes as explained above.
>
> This only happens while processing generic lambda because
> processing_template_decl is 1,
> so finish_compound_literal returns {} instead of a TARGET_EXPR.
So I think we should disable the above assert if
processing_template_decl; the CONSTRUCTOR is actually fine here.
> Part of r256550 was this change:
>
> @@ -8640,9 +8642,9 @@ finish_static_assert (tree condition, tree message,
> location_t location,
> }
>
> /* Fold the expression and convert it to a boolean value. */
> - condition = instantiate_non_dependent_expr (condition);
> - condition = cp_convert (boolean_type_node, condition, tf_warning_or_error);
> - condition = maybe_constant_value (condition);
> + condition = perform_implicit_conversion_flags (boolean_type_node,
> condition,
> + complain, LOOKUP_NORMAL);
> + condition = fold_non_dependent_expr (condition);
>
> if (TREE_CODE (condition) == INTEGER_CST && !integer_zerop (condition))
> /* Do nothing; the condition is satisfied. */
>
> where instantiate_non_dependent_expr turned {} into TARGET_EXPR <D.2369, {}>,
> which we can process just fine. So perhaps we need to put the call back.
The problem with that is that fold_non_dependent_expr does
instantiate_non_dependent_expr, so adding the call back would mean
instantiating twice in a row, which is likely to break.
Let's just adjust the assert.
Jason
