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...