The pass has been unplugged from the pipeline since 189173d (Jul 2023),
when the IR-level DCE over the UberModule took over, and the 2026-07-02
backend audit showed it would miscompile if re-enabled (PreserveReturned
drops all top-level field assignments). Moved to the lua-dce-wip branch
with its defect list documented; a pointer comment in compileModules
marks where it would be wired back.

chore: park the unused Lua-level DCE on the lua-dce-wip branch

…ations

perf: disable pushDeclarationsDownTheInnerScope (#136)

…mes (#133)

The RecursiveGroup branch of renameShadowedNamesInExpr had two defects:

1. The fold consed processed members onto an accumulator and never
   reversed the result, so every local recursive group came out with
   its members in reverse order. Member order is the initialization
   order computed by the laziness transform, so eager members (e.g. the
   `name = Lazy_name(0)` forcing bindings) could run before the members
   they read were assigned, producing nil at runtime.

2. Each member's RHS was renamed in the scope accumulated over the
   previous members only, while recursive-group scoping makes every
   member visible in every member's RHS, itself included (see
   Note [Sequential scoping of Let bindings]). When a group member
   shadowed an outer binder, self- and forward references kept the old
   name and silently rebound to the outer binder.

The branch now brings all the members into scope first (avoiding the
names bound anywhere in the group), then renames every RHS in the
complete group scope, preserving member order.

The Golden.RecGroupOrder test pins the runtime consequence: its lazy
self-reference compiles to a Lazy_record/record pair whose order is
load-bearing; with the old code the generated Lua crashed with
"attempt to call local 'Lazy_record' (a nil value)".

The Golden.RecursiveBindings churn is the reversal disappearing: member
order now matches what the laziness transform emits.

fix: preserve order and scope of recursive groups in renameShadowedNames

…R DCE (#134)

Two defects in the Let handling of IR dead code elimination, both of
the De Bruijn bookkeeping class of #37/#56:

1. Dropping a dead binding from a Let removed a slot from that name's
   De Bruijn namespace without lowering the references that skipped
   over it, unlike the Abs case (fixed in #56). A dangling reference
   either crashed the Lua codegen with UnexpectedRefBound or silently
   resolved to the wrong binder. The Let case of dceAnnotatedExp now
   walks the groupings left to right and, for every dropped binder,
   unshifts the rest of the Let (later grouping RHSs and the body).
   The unshift traversal is reused by wrapping the remainder back into
   a Let, so the scope threading follows
   Note [Sequential scoping of Let bindings] instead of being
   re-implemented.

2. The scope the Let body was resolved against in adjacencyListForExpr
   was built with a foldr, putting the *first* binding of a name at
   index 0 where the let* convention requires the *last*. Reachability
   thus marked the wrong binding live among same-name siblings. The
   body now uses the same scope that adjacencyListForGrouping threads
   through the groupings.

Both defects are latent on the current corpus (no golden churn):
same-name Let siblings cannot be produced from source today, and the
dangling-reference path needs an inliner-created shadowing binder
whose uses later die. Regression tests pin the semantics at the DCE
level; an end-to-end golden can follow once a source-level
reproduction for the second path is pinned down.

fix: unshift dropped Let binders and resolve body scope per let* in IR DCE

'Rewritten Recurse' descends into the rewritten node's children without
re-applying the rule to the node itself. When every binding of a Let is
dead and the node collapses to its body, a body that is itself a Let
escaped the DCE rule: its dead bindings were kept, while the parameters
of lambdas inside them were blanked (their ids are unreachable), leaving
unbound local references in the intermediate IR. A later optimizer
iteration always dropped the residue, so generated code was unaffected;
the per-pass invariant checks built for #138 surfaced the bug on the
golden corpus (Golden.LongWriterBind, Control.Monad.Writer.Trans).

Process a collapsed-into Let directly in the rule (the collapse can
cascade), so its dead bindings are eliminated in the same pass.

…138)

The IR pipeline becomes a list of Step values interpreted by runners: a
Pass carries its invariant contract (passRequires/passEnsures), and the
Step layer (RunPass | RunFixpoint) lets the checked runner lint every
pass boundary including every fixpoint iteration — an intermediate
violation masked by a later iteration is exactly what it exists to
catch. Components:

- IR.Supply: deterministic counter-based name supply threaded through
  passRun; flattenDeepBinds ports its internal counter to it (names are
  bit-identical: nothing draws before it, the counter starts at 0).
- IR.Linter: well-scopedness check generalized from the Optimizer
  spec's unboundLocals reference implementation; walks bindings,
  foreigns, and exports, and treats the runtime lazy factory as bound
  by the runtime (a fifth site of the PSLUA_runtime_lazy coupling).
- IR.Pass: Invariant, Pass, Step, PassCheckFailure, and the three
  runners (plain, checked, traced); idempotently moves here.
- The golden harness compiles through the checked runner, so every
  golden module doubles as a scope-invariant test of the pipeline.
- The CLI gains a --lint-ir debug flag plumbed through compileModules.

Behavior-identical: zero golden churn (guarded by the kont0/tmp0 names
baked into the Long*Bind goldens).

…iew)

First-class passes for the IR pipeline: Pass values, invariant checks, deterministic name supply