gen-verilog: on_clock with a return type emits an assignment to an implicitly-declared identifier under default_nettype none

Found while trying to close #2266 at the spec layer. Built from master cf1265312486e02ddf6b7375814a82301130bed6.

Defect

on_clock lowers to an always @(posedge clk or negedge rst_n) block, not to a Verilog function — so there is no identifier of that name to receive a return value. But gen_verilog_fn_body lowers return / a trailing call expression to an assignment to self.current_fn_name, which for this path is the literal string on_clock. The result is an assignment to an identifier that was never declared.

Reproduction

Patch specs/fpga/uart.t27:224 from

fn on_comb(data: u8) -> bool { return uart_tx_send(data); }

to

fn on_clock(data: u8) -> void { uart_tx_send(data); }

t27c gen-verilog specs/fpga/uart.t27 emits:

    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) begin
        end else if (en) begin
            on_clock <= uart_tx_send(data);
        end
    end

on_clock is declared nowhere in the module. yosys 0.63:

Warning: wire '\on_clock' is assigned in a block at fixA.v:175.13-175.43.
fixA.v:175: Warning: Identifier `\on_clock' is implicitly declared.

The file opens with `default_nettype none, under which an implicit net declaration is not supposed to be legal at all; yosys downgrades it to a warning, so it passes silently.

Using -> bool with an explicit return produces the same thing with a blocking assign (on_clock = uart_tx_send(data);).

Suggested shape

Either refuse an on_clock that declares a return type (it has no port to drive — the boundary for a clocked entry point is an exposed var, not a return value), or bind the value to a declared local. Refusing is the stricter side and matches the W699/T190b precedent already in this file.

Relationship to other issues

Independent of #2363, which is about assignments being dropped from the same block. Both were hit while attempting the spec-level repair for #2266.

Boundary

specs/fpga/uart.t27

User Scenarios

Given a T27 spec containing fn on_clock(data: u8) -> void { uart_tx_send(data); }, when t27c gen-verilog compiles it, then the emitted Verilog must not assign to an undeclared identifier on_clock inside the always @(posedge clk ...) block.
Given a T27 spec containing fn on_clock(data: u8) -> bool { return uart_tx_send(data); }, when t27c gen-verilog compiles it, then the compiler must reject the spec with a clear diagnostic rather than emitting an assignment to an implicitly-declared net.

Requirements

FR-001: The compiler MUST reject any fn on_clock that declares a non-void return type with a diagnostic at the call site.
FR-002: The compiler MUST reject any fn on_clock that declares -> void but contains a trailing expression (implicit return) with a diagnostic at the call site.
FR-003: The compiler MUST accept fn on_clock(...) -> void { /* statements only, no trailing expr */ } and lower it to a clocked always block with no assignment to on_clock.

Success Criteria

t27c gen-verilog specs/fpga/uart.t27 exits 0 and the emitted Verilog contains no assignment to on_clock inside the always @(posedge clk ...) block.
Compiling a spec with fn on_clock(...) -> bool { ... } produces a compiler error (non-zero exit) and the error message references the return type on on_clock.
Compiling a spec with fn on_clock(...) -> void { expr; } (trailing expression) produces a compiler error (non-zero exit) and the error message references the trailing expression.
3 tests in the test suite cover these three cases and all pass.

Note from #2363, which is now closed by #2380 (merged, 2d2eafe79).

The blocker under this issue is gone: on_clock no longer drops a body statement whose RHS does not mention the assigned var. The cause was dead_store_elim — it runs per function body, treats a simple-identifier LHS as a pure write, and deleted the store because nothing later in the body read the name. A module-level var is not function-local; the Verilog backend emits it as an output reg port.

This issue is unaffected and stays open. The on_clock <= uart_tx_send(data); shape reported here comes from gen_verilog_fn_body's tail-expression / return lowering assigning to self.current_fn_name, which for the clocked path is the literal string on_clock. That is a different code path from the one #2363 touched, and #2380 changed nothing in it — deliberately, to keep the diff to the defect it was reproducing.

One detail that may matter to whoever takes this: the reproduction quoted here shows an EMPTY reset arm

        if (!rst_n) begin
        end else if (en) begin
            on_clock <= uart_tx_send(data);

The reset arm is emitted from the module's scalar var declarations, independently of the body, so that emptiness is about the spec's vars, not about the drop #2363 described. #2363's signature is the opposite one: a populated reset arm with an empty en arm.

A boundary drafted from the paths this issue already names, so a bee can take it. Nothing is reserved until this is in the issue body - the Queen reads the body, not comments. Check the paths first: a wrong boundary reserves files the work does not own.

Boundary

specs/fpga/uart.t27

docs: the coordination entry this branch needs to land

gen-verilog: on_clock with a return type emits an assignment to an im…

Reopening: the compiler defect this issue names is still live on master.

942a001 (#4651), whose message closed this issue, changed the spec rather than the compiler. It pasted this issue's reproduction into specs/fpga/uart.t27, replacing fn on_comb(data: u8) -> bool { return uart_tx_send(data); } with an on_clock body. On master, gen-verilog of that spec still emits an assignment to an undeclared on_clock, and iverilog says uart.v:175: Could not find variable on_clock in ZeroDSP_UART. That is the second of the two errors the FPGA elaboration ratchet counted (178 vs baseline 176) since 2026-09-22.

PR #5948 (Closes #5908) restores the on_comb line, so uart is back to 0 errors. It does not fix the compiler, so this issue has no fix yet. A fix needs a bootstrap/ change and a test that runs gen-verilog on an on_clock with a return type under default_nettype none.

Refs #5906

Review of the bee branch queen-2364 (review-jam sweep, lane A).

Not accepted, and not releasable to a bee. The branch adds nothing: master already carries the reproduction, fn on_clock(data: u8) -> void { uart_tx_send(data); }. The defect is still live. On the Railway t27c lab at master 13e212a, t27c gen-verilog specs/fpga/uart.t27 | grep -cE '^ *on_clock <?= ' prints 1: an assignment to the undeclared identifier on_clock.

What a correct answer needs. A change to gen_verilog_fn_body in bootstrap/ that does one of two things: refuse an on_clock with a return value or trailing call, or bind the value to a declared local. That is hand-written Rust. Under the only-t27 rule it needs the owner's owner-approved-foreign label before anyone may write it. A spec-only answer would only hide the defect by removing the reproduction from uart.t27. Escalating to the owner; I left the criteria unchanged.

fix(fpga): restore uart on_comb, record clean adapter, name ternary_i…

Add test cases for on_clock function validation

Navigation Menu

Repository navigation

gen-verilog: on_clock with a return type emits an assignment to an implicitly-declared identifier under `default_nettype none` #2364

Defect

Reproduction

Suggested shape

Relationship to other issues

Boundary

User Scenarios

Requirements

Success Criteria

Boundary

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

gen-verilog: on_clock with a return type emits an assignment to an implicitly-declared identifier under default_nettype none #2364

Description

Defect

Reproduction

Suggested shape

Relationship to other issues

Boundary

User Scenarios

Requirements

Success Criteria

Activity

gHashTag commented on Aug 22, 2026

gHashTag commented on Sep 23, 2026

Boundary

gHashTag commented on Oct 4, 2026

gHashTag commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

gen-verilog: on_clock with a return type emits an assignment to an implicitly-declared identifier under `default_nettype none` #2364