gen-c: a module-level array constant puts its brackets before the name #3457

What

const A : [4]u8 = [1,2,3,4];

static const [4]u8 A = { 1, 2, 3, 4 };

error: brackets are not allowed here; to declare an array, place the brackets after the identifier
error: type specifier missing, defaults to 'int'
error: expected ';' after top level declarator

The mutable twin four lines above in the emitter has the same defect: var A : [4]u8 gives static [4]u8 A = { … }.

And a slice constant, which predates both: const A : []u8 = [1,2,3] gives static const []u8 A. T name[] = { … } is legal C and takes its size from the list.

Fourth position for one rule

The repair builds the declarator from the field helper rather than writing a fourth copy of the rule.

Measured — whole corpus, -ferror-limit=0

Largest: math/e8_lie_algebra 44 → 4, fpga/mac 101 → 85, queen/lotus 29 → 16, boards/xc7a100t_minimal 11 → 1.

One file's count rose and it is not a regression. isa/registers goes 34 → 44 because the declarations now parse: the errors that disappear are brackets are not allowed here, expected ';' after top level declarator, expected ';' at end of declaration, and what appears behind them is semantic — TernaryWord{.raw=0} is not C, a separate defect that the parse cascade had been hiding. A raw error count is not monotone under a repair that fixes a parse error.

Found by

Round six of tools/backend_parity_table.py — the const-initialiser position, which the table had never covered. The previous round found only latent defects; this one found a live one on its first form.