parser: generic const struct declaration 'pub const Name(T) = struct' does not parse

[gHashTag]

Found while repairing corpus damage (#2160), and only observable AFTER that repair: these ten files previously failed earlier in the file for a different reason, which masked this.

$ t27c parse specs/tri/collections/stack.t27   # with the damage repaired
Error: Parse error: parse error at module level near line 13:
Unexpected token in expression: KwStruct ('struct') at line 13:26

Line 13 is pub const Stack(T) = struct {. The parameterised const form is accepted lexically but the parser does not reach struct on the right-hand side.

Ten files, all identical in shape:

file	declaration
specs/tri/collections/btree.t27	pub const BTree(K, V) = struct {
specs/tri/collections/lru.t27	pub const LRU(K, V) = struct {
specs/tri/collections/map.t27	pub const Map(K, V) = struct {
specs/tri/collections/queue.t27	pub const Queue(T) = struct {
specs/tri/collections/ring_buffer.t27	pub const Ring(T) = struct {
specs/tri/collections/skip_list.t27	pub const SkipNode(T) = struct {
specs/tri/collections/stack.t27	pub const Stack(T) = struct {
specs/tri/collections/variant.t27	pub const Variant(T) = struct {
specs/tri/graph/graph.t27	pub const Graph(T) = struct {
specs/tri/pipeline/builder.t27	pub const Builder(T) = struct {

Non-generic pub const Name = struct { parses; the difference is the parameter list.

Reproduce: tri damage-repair --combined --apply-to /tmp/repaired_all, then parse the files above from that tree.

Open question before any fix: whether pub const Name(T) = struct is intended surface syntax at all, or whether the corpus is using a form the language never adopted. Ten files using it consistently is evidence of intent but not a specification. That decision belongs to the language owner and it determines whether this is a parser bug or a corpus issue.

[gHashTag]

Language decision recorded (owner, 2026-08-15)

This comment exists because the decision was taken in a working session and never
written down here. An hourly tick independently re-measured this issue and closed
with outcome B, blocked: waiting on the language owner, while the decision had
in fact already been made. A decision that lives only in a conversation is, from
the point of view of every automated consumer, not a decision at all.

Decision. pub const Name(T) = struct { ... } is accepted as a legitimate
parameterised type declaration. The parser must accept it as
ConstDecl(name, generic_parameters, StructExpr). This issue is therefore a
parser defect, not a corpus error, and the 28 files using the form are not to
be rewritten.

Measured, on this pair (/tmp/t27c.m2162base -> /tmp/t27c.m2162fix):

figure	value
declarations of the form in the corpus	33 in 28 files, all with struct on the right [measured]
positive fixtures rejected by the old binary	6 of 6 [measured]
positive fixtures accepted by the candidate	6 of 6 [measured]
cargo test --test generic_const_decl	16 / 16 [measured]
cargo test --bin t27c	1537 passed, 0 failed, 2 ignored [measured]

The AST contract was fixed before implementation in
architecture/ADR-008-parameterised-const-type-declaration.md, so the tests
cannot be read as having been fitted to whatever the patch happened to do.

Two things this decision does NOT settle, kept separate on purpose:

• Generic type APPLICATION (Name(T) in a type position) is rejected; 20 library specs, needs a language decision #2164 — Name(T) in type application position (using the type, not
  declaring it). Accepting the declaration does not imply accepting the
  application; that needs its own short ADR. Left as needs-language-ADR.
• 'test' as a reserved word blocks 'fn test(...)'; contextual-keyword decision needed (1 spec affected) #2165 — whether test is a reserved word. Unaffected by this decision, and
  not to be guessed at from one spec file.

Honest limit on the numbers above. They come from a differential measurement
whose unchanged category was, until this session, overloaded: it counted files
where neither binary parsed as agreement. Re-measured with a separate
not-evaluated category, the same library run reports coverage explicitly. The
figures in the table are unaffected — they are fixture and test counts, not
aggregate corpus counts — but any corpus-wide "no regressions" phrasing from
earlier ticks should be read as bounded by the coverage figure now printed.