CompileStmt: a non-ANSI function's local arrays keep their unpacked dimension

[alaindargelas]

What

A function whose ports are tf_item_declarations (input [31:0] idx; inside the body) has its following data declarations compiled by compileTfPortDecl, which rebuilt each local from its data type alone (compileVariable on reg [63:0]) and dropped the unpacked dimension written after the name: reg [63:0] tbl [0:3]; came out as a 64-bit logic_var, and every tbl[i] as a one-bit select. The ANSI body path (compileStmt → compileDataDeclaration) keeps the dimension and produces an array_var.

compileTfPortDecl now routes the declaration through compileDataDeclaration and collects the variables it declares (no scope is passed, since compileFunction installs the function's variable list from the vector returned here). The port-redeclaration case (input a; reg [7:0] a;, which only retypes the io_decl) is unchanged.

Why

Constant functions written in Verilog-2001 style (most of Alex Forencich's verilog-ethernet / verilog-axis helpers) keep their tables in function-scope unpacked arrays; the UHDM consumer saw a scalar and computed nothing useful.

Test

tests/TfItemUnpackedLocal: the golden shows work@dut.f0.tbl as an array_var with four 64-bit entries. Full scripts/regression.py run: see the final comment.

Prepared with the assistance of Claude Code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XshwvRJtjR5dA48M4b1CLM

[alaindargelas]

Full scripts/regression.py run (828 tests, superbuild-built binary): 0 FAIL / 0 TOOLFAIL; 22 goldens updated in this PR, all of the same kind — the UVM 1.2 library and a few tests (TaskDecls, SimpleParserTest, BuildUVMPkg, TfItemUnpackedLocal) declare locals the non-ANSI way, so their unpacked locals are now array_var (object counts: +6 array_var / +6 array_typespec per UVM-based test) and the declaration locations point at the variable name. No ERROR/WARNING line changes anywhere (git diff -U0 -- tests third_party/tests | grep -E '^[-+]\[(ERR|FATAL)' is empty).