|
|
@@ -48,3 +48,19 @@ exactly one error: `b_bad_ret` 232, `b_bad_nest` 230, `b_bad_dup` 200.
|
|
|
|
|
|
`DEFINITION`/`IMPLEMENTATION` split (the remaining big item), `WITH`-field
|
|
|
`VAR` actuals, `CHAR`/`BOOLEAN` tails as `VAR` actuals, open-to-open.
|
|
|
+
|
|
|
+## Post-step fix — init/proc table-slot collision (new commit on top)
|
|
|
+
|
|
|
+Showcase3 (`A.x*100 + B.y + C.cnt + D.val` = 168) exposed a real bug:
|
|
|
+with an early plain init plus a later procedure-owning module, the run
|
|
|
+printed 72 (`A.x` = 0, `C.cnt` = 15). Root cause: `ModInitBegin` took
|
|
|
+`maxNum+1` from emission order while `SymTab` numbers procedures from a
|
|
|
+separate declaration-order pool — so module A's init stole `C.Inc`'s
|
|
|
+number 1, and `ProcEntry(1)` for `Inc` overwrote the init's table cell
|
|
|
+(startup then called `Inc` instead of A's init: 5 + 10 = 15 in `cnt`,
|
|
|
+`x` never assigned). Single-module tests passed only because each
|
|
|
+procedure body was emitted before its module's init. Fix: init numbers
|
|
|
+now come from `SymTab.AllocInitNum()`, sharing the `nProcs` pool
|
|
|
+(`procs[]` entry initialized like a parameterless proper procedure).
|
|
|
+Regression `b_mix` (110) locks the shape; suite 144/144, Showcases
|
|
|
+unchanged (157, 83), Showcase3 prints 168.
|