Migrate Rust-style `[T; N]` array syntax to Home `[N]T` in kernel sources

Context

Audit (2026-05-01) found that of 166 kernel modules that fail to parse, a notable cluster fail with the same root cause: declarations using Rust's array type syntax `[T; N]` instead of Home's `[N]T`.

Examples found by inspection:

• `drivers/pci.home:93` — `var pci_bus_visited: [u8; 32]`
• `arch/arm64/rpi/uart.home:241` — `buffer: [u8; UART_BUFFER_SIZE]`

The parser surfaces these as `Expected '{'` or `Expected ',' after type argument` (9 + 8 = 17 captured cases), but the actual count is higher — the `home ast` subcommand hangs after the first parse error so 110/166 parse failures couldn't be classified beyond timeout.

Affected files (confirmed)

Almost certainly more once a clean parser pass is possible. From inspection of the captured first-error sample:

• All files under `kernel/src/arch/arm64/rpi/` (10 modules)
• `kernel/src/drivers/pci.home`
• `kernel/src/drivers/spi.home`
• `kernel/src/drivers/gpio.home`
• `kernel/src/drivers/bluetooth.home`
• `kernel/src/drivers/nvme.home`
• `kernel/src/drivers/keyboard.home`
• `kernel/src/drivers/ahci.home`

Proposal

• Sweep `kernel/src/**/.home` for the pattern `\[\s[A-Za-z_][^,\]]\s;\s*[^\]]+\]` (regex; will catch most cases — false positives possible in array-literal contexts so review each)
• Replace `[T; N]` → `[N]T` in type position. Do not touch array-literal positions (those are different syntax).
• Easiest as a small codemod — `scripts/codemod-array-syntax.sh` or similar, run once and discard
• Validate by running `home ast` on each touched file post-rewrite (or just compile the kernel after — parse errors are loud)

Risk

The pattern is mechanical but the `home ast` post-error hang means iteration is slow until home-lang/home fixes that (separate issue worth filing). Sweep + manual review per file is the pragmatic path.

Audit reference

`~/Desktop/home-os-kernel-audit-2026-05-01.tsv` on the maintainer's machine. Filter: `parse_status=FAIL` rows where `first_error` matches `Expected '{'` or `Expected ','`.

Closing — premise was inverted

Investigation today shows the audit's diagnosis was wrong. Documenting findings so the next pass starts from the right place.

What the audit thought

`[T; N]` in kernel files is Rust syntax that needs to become Home's `[N]T`.

What's actually true

`[T; N]` is Home's fixed-size array syntax. Confirmed by reading the parser source:

• `packages/parser/src/parser.zig:1486` — typedef path explicitly handles `[T; N]`
• `packages/parser/src/parser.zig:1966` — `parseTypeAnnotation` accepts the same form

Minimal repros all parse cleanly: ```home var x: [u8; 32] # parses type Foo = [u8; 32] # parses fn foo(x: [u8; 32]) {} # parses struct S { buf: [u8; 32] } # parses ```

In the AST output for the actual `drivers/pci.home`, `let mut pci_devices: [PCIDevice; 64]` (line ~23) parses fine. The failure on line 93 (`var pci_bus_visited: [u8; 32]`) only surfaces after a prior `<unknown-stmt>` shows up earlier in the file — i.e., the parser is in a degraded state from an upstream error and the line-93 message is a downstream symptom, not a real syntax problem.

What we still know

The kernel still has 166 parse-failing modules per the audit. The dominant failure mode is not Rust-style array syntax. To find the real causes we need:

1. Issue #16 fixed first (parser hangs after first error), so `home ast` exits with diagnostics instead of timing out.
2. A re-run of the audit afterwards. With the parser actually surfacing first-real-errors, the parse-failure bucket should classify cleanly and we can file targeted issues.

Side finding worth filing later

`var` declarations at module scope appear to interact badly with array types after an earlier parse error in the same file — surfaces a misleading `Expected '{'` message. Worth a focused bug once #16 is in.

Action taken

• Codemod attempt (194 files rewritten to `[N]T`) discarded — the rewrite would have broken working code.
• No commits, no force-pushes, no remote impact.
• This issue closed; reopen or file a new one once #16 unblocks proper triage.