On 01/17/2014 06:02 PM, Jason Merrill wrote:
OK.
Thanks.
Does returning error_mark_node from build_value_init in the case of
erroneous type not work?
Yeah, doesn't work in the sense that we regress to two errors instead of
one (like in 4.8.x) on that testcase I mentioned at the beginning of
t
OK.
Does returning error_mark_node from build_value_init in the case of
erroneous type not work?
Jason
.. patchlet fixes c++/58811 too.
Paolo.
Hi,
On 01/15/2014 08:45 PM, Jason Merrill wrote:
On 01/15/2014 07:54 AM, Paolo Carlini wrote:
It seems Ok to me, and passes testing, to
return NULL_TREE from build_value_init. Alternately, more
conservatively, we could change build_value_init_noctor to not call
build_value_init at all when ftyp
On 01/15/2014 07:54 AM, Paolo Carlini wrote:
It seems Ok to me, and passes testing, to
return NULL_TREE from build_value_init. Alternately, more
conservatively, we could change build_value_init_noctor to not call
build_value_init at all when ftype == error_mark_node.
I think I would prefer that
Hi,
this is a 4.9 Regression, but just an ICE on invalid. It's a little
tricky to fix, because, eg, in mainline (vs 4_8-branch) we want to
produce somewhat more concise diagnostic in this area (eg, a single
error for init/array26.C). It seems Ok to me, and passes testing, to
return NULL_TREE
