On Wed, Jan 15, 2025 at 04:33:26PM +0100, Jakub Jelinek wrote:
> I vaguely remember from writing the original patch (which introduced
> cp_maybe_split_raw_data) that here it actually mattered whether
> in the error case we move the reshape_iter or not and that it broke
> some tests, but I no longer remember what was it exactly.
> Otherwise it would also just use consume_init like most of the other
> cases.
> I can surely try without that again and see what breaks.
Ah, seems there is not a single testcase which tests has_designator_problem
complaining about the second half of a _Complex.
But, the issue is that the code before my changes was testing it too late:
vec<constructor_elt, va_gc> *v = 0;
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, d->cur->value);
if (has_designator_problem (d, complain))
return error_mark_node;
d->cur++;
and because has_designator_problem looks at d->cur->index, obviously
incrementing d->cur first isn't a good idea.
I'll test if I can go with
if (error_operand_p (d->cur->value)
|| has_designator_problem (d, complain))
return error_mark_node;
vec<constructor_elt, va_gc> *v = 0;
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
init = consume_init (d->cur->value, d);
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, init);
init = build_constructor (init_list_type_node, v);
which matches how it is done for the first half of the _Complex,
where we do
tree init = d->cur->value;
if (error_operand_p (init))
return error_mark_node;
if (first_initializer_p && !CP_AGGREGATE_TYPE_P (type)
&& has_designator_problem (d, complain))
return error_mark_node;
..
init = consume_init (init, d);
(note, this is inside of first_initializer_p guarded code and type is known
to be COMPLEX_TYPE, so non-aggregate).
Jakub
