On Fri, Dec 16, 2011 at 10:40 AM, Dodji Seketeli <do...@redhat.com> wrote:
> Hello,

> So I am thinking that maybe letting expand_default_init represent the
> invalid initialization would prevent us from getting into this case.
> For that to work I had to make
> build_constexpr_constructor_member_initializers try a little bit
> harder to represent invalid member initialization, as that code wasn't
> expecting to have e.g, an EXPR_STMT for a member initialization.

Ideally, we should have erroneous member inits be initialized with
error_mark_node.

>
> If you think I am trying too hard, maybe I could just get out early
> from register_constexpr_fundef if errorcount is non-zero?  Like, right
> before:
>
>  if (DECL_CONSTRUCTOR_P (fun)
>      && cx_check_missing_mem_inits (fun, body, !DECL_GENERATED_P (fun)))
>    return NULL;
>
> ?
>
> The reason why I am not doing this straight away is that I am thinking
> that maybe G++ could be missing some diagnostic in that case.  And
> more generally, I think that representing invalid input (as much as we
> can) in the semantic tree is consistent with what's done in the rest
> of the FE and leads to better diagnostics.

We don't have a good track record at invalid input around for too long :-)
Plus, keeping invalid input around for too long means that other part
of the front-end gets messed up with hairy conditionals and control flows.
I would think that an erroneous member initialized already got a
 diagnostic and that should suffice and we shouldn't keep trying further...

Reply via email to