A prefix/postfix increment or decrement (`x++`, `--x`, ...) is desugared into a
block holding an induction temporary. The two frontends name that temporary
differently:
- K1 uses a per-scope counter, `tmp0`, `tmp1`, ... `tmpN`.
- K2 uses the uniform special name `<unary>`.
Decision: adopt the K2 name (`<unary>`) from both frontends. This is the only
robust convergence direction: K1's counter-based `tmpN` numbering depends on the
frontend's temporary allocation order and cannot be reproduced faithfully under
K2 (mapping `<unary>` back to a single `tmp0` would wrongly collapse distinct
temporaries such as `tmp0`..`tmp7` in one function). The uniform `<unary>` name
is frontend-independent and identifies the construct just as well. (This
supersedes the earlier D14 preference for the readable `tmpN` names, which was
made before the numbering infeasibility was established.)
Implementation: `extractBlock` recognises an `IrContainerExpression` whose origin
is one of PREFIX_INCR / PREFIX_DECR / POSTFIX_INCR / POSTFIX_DECR and records its
first statement (the induction temporary) together with the canonical name
`<unary>`. `extractVariableExpr` emits that name for exactly that variable (matched
by identity), leaving all other locals untouched. The recording is saved/restored
around the block's statement extraction so nested blocks behave correctly. The
detection is origin-based and therefore identical for K1 and K2.
Full dual-suite relearn: all 3333 tests pass. The only changed rows are in
test-kotlin1 (exprs/exprs, exprs/PrintAst, controlflow/basic/bbStmts and
getASuccessor), where the K1 increment temporaries converge from `tmpN` to
`<unary>`, matching K2. Remaining exprs.kt differences (unary-operand span, and
the delegatedProperties `<set-?>`/`<get-x>` cluster) are separate location/naming
items tracked elsewhere. The destructuring container temp (`tmp0_container` vs
`<destruct>`) is handled separately in C14b.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
f8e33a2742