Owner decision: emitted Verilog carries widths that cannot be real, and the release build is the one that hides it #2566

gen-verilog emits ranges no hardware can carry, exits 0, and prints nothing to stderr. Ten specs, three distinct mechanisms.

What the build flag decides

VerilogCodegen::range_decl(width: u32) (bootstrap/src/compiler.rs:9591) formats [width - 1 : 0] and guards only width == 1. A packed width of 0 underflows:

CI builds --release. So Corpus ratchet has been green over this, and the loud version of the bug is the one CI can never see. Reproduce:

cargo build --release -p t27c
t27c gen-verilog specs/fpga/formal.t27 | grep 4294967295

Three mechanisms, not one

A detector keyed on the literal 4294967295 finds 8 of the 10. This one keys on "no real bus is a million bits wide" and finds all three classes.

Why this is yours and not mine

compiler.rs is sealed by stage0/FROZEN_HASH, and FROZEN.md reserves re-sealing for a deliberate M5 ceremony by maintainers. I have not touched it.

The design question is also yours: should a type with no bit representation be lowerable to Verilog at all? Refusing would be correct and would fail these ten specs, which is a ratchet decision, not a bug fix.

What I did instead

tools/check_verilog_widths.py with tools/verilog_width_baseline.txt ledgers the ten so the eleventh fails. It treats the debug panic and the release emission as the same finding, because a checker that scanned only emitted text would report CLEAN against a debug compiler — the compiler that panicked emitted nothing to scan, and absence of the string is not absence of the defect.

Boundary

• specs/compiler/stdlib.t27
• specs/fpga/formal.t27
• specs/memory/notebooklm.t27
• bootstrap/src/compiler.rs
• tools/check_verilog_widths.py
• tools/verilog_width_baseline.txt

User Scenarios

• Given a spec with a type that has no bit representation (e.g., CoverPoint struct of strings), when t27c gen-verilog runs in release mode, then it emits a Verilog range [4294967295:0] and exits 0 with empty stderr.
• Given a spec that flattens a Map to 4.2 million bits, when t27c gen-verilog runs in release mode, then it emits a Verilog range [4198430:0] and exits 0 with empty stderr.
• Given a spec exercising the u64 code path, when t27c gen-verilog runs in release mode, then it emits a Verilog range [18446744073709551615:0] and exits 0 with empty stderr.

Requirements

• FR-001: VerilogCodegen::range_decl MUST reject width == 0 before underflow can occur, in both debug and release builds.
• FR-002: The compiler MUST emit a diagnostic to stderr and exit non-zero when a type with no bit representation is passed to Verilog codegen.
• FR-003: The compiler MUST emit a diagnostic to stderr and exit non-zero when a packed width exceeds a configurable maximum (e.g., 1_000_000 bits).
• FR-004: tools/check_verilog_widths.py MUST fail (exit non-zero) when any emitted Verilog contains a range upper bound ≥ 1_000_000.
• FR-005: The baseline tools/verilog_width_baseline.txt MUST be updated to reflect the ten known offending specs as expected failures.

Success Criteria

• cargo build --release -p t27c && t27c gen-verilog specs/fpga/formal.t27 exits non-zero and prints a diagnostic mentioning width 0 or excessive width.
• cargo build --release -p t27c && t27c gen-verilog specs/memory/notebooklm.t27 exits non-zero and prints a diagnostic mentioning width 0 or excessive width.
• cargo build --release -p t27c && t27c gen-verilog specs/compiler/stdlib.t27 exits non-zero and prints a diagnostic mentioning excessive width.
• python tools/check_verilog_widths.py exits 0 after the fix (baseline updated, no new findings).
• Zero occurrences of 4294967295, 18446744073709551615, or 4198431 as range upper bounds in any t27c gen-verilog output across the three cited specs.