Gabriel Dos Reis <g...@integrable-solutions.net> writes:
> 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.
With that patch, the EXPR_STMT wraps an error_mark_node. But yes, I
agree.
> 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...
OK. Thanks.
--
Dodji
