Class LoopActivationOwnership

java.lang.Object
org.ek9lang.compiler.phase9.LoopActivationOwnership

final class LoopActivationOwnership extends Object
The two ownership rules that need to know which instruction lists run once per loop ITERATION (an activation), not just which scope ids exist - EK9_IR_OWNERSHIP_MODEL.md ยง12, stage 0, stated in today's opcodes:
  • A value is owned by the activation that makes it (model V-F, the A11 rule). A _temp is defined once per execution of the list it is in, so registering it, from inside a loop's per-iteration list, into a scope that was entered OUTSIDE that loop gives one scope exit for every iteration's value: all but the last leak.
  • A slot rebound in a loop has an owner for its last value (model V-G, the A10 rule). A variable declared outside a loop and STOREd inside it is released, value by value, by each rebind; its LAST value needs a scope that releases its current value (SCOPE_REGISTER of a named variable or a _slot) or an explicit RELEASE after the loop - or, in the ownership form, a move out of it after the loop (a consuming SLOT_ASSIGN that takes it, as a loop expression's result is taken). A _temp name does not qualify through registration: a registered temp is a single value, so a native back end releases the value it had when registered.

Per-iteration lists: a loop chain's condition, body and guard updates (WHILE / DO-WHILE, statement and expression forms), and a for-range's body, continue condition, loop-condition templates, body setups, increments, value guards and progress checks. Every other nested list (if/switch arms, logical operands, literal set-up, try, finally) belongs to the activation it sits in - each composite says which of its lists run per iteration (CompositeInstr.nestedLists()), and the walk is IRStructureWalk. Used by RetainReleaseBalanceVerifier.

  • Method Details

    • check

      static List<String> check(List<IRInstr> body, Set<String> returnVariables)
      The problems in one operation body, in walk order; empty when it keeps both rules.
      Parameters:
      body - the operation's instructions
      returnVariables - the operation's return variables, owned by the caller and so never checked
    • movedOutOf

      static Set<String> movedOutOf(List<IRInstr> body)
      The variables an operation body's ownership form moves out of (the value of a consuming SLOT_ASSIGN). Lowering a move leaves a bare STORE, so the lowered form no longer shows that a variable's last value left it; this rule has already judged those moves on the ownership form, and OwnershipLowering's V-L check passes them back so it does not re-ask about evidence the lowering legitimately removed.
      Parameters:
      body - an operation body still in the ownership form