Class InstructionBlockVariablesOrError

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.common.TypedSymbolAccess
org.ek9lang.compiler.phase3.InstructionBlockVariablesOrError
All Implemented Interfaces:
Consumer<EK9Parser.InstructionBlockContext>
final class InstructionBlockVariablesOrError extends TypedSymbolAccess implements Consumer<EK9Parser.InstructionBlockContext>
Checks that variable only and variable declarations have symbols that have been referenced. This is a bit like 'golang', it is considered an error if accessed before initialising or if not used. There are a couple of exceptions around 'injection' as that can only really be detected at runtime (hence avoid).

One verdict is DEFERRED to PRE_IR_CHECKS (E08090, item 5): a variable initialised by a CALL whose later uses are only in-place mutations (view <- config.get("server"); view :~: overrides). The call may have handed back a view of something that IS read later, and then mutating it is a use - which only the callee's RETAINS can say, and for a user method or function that is derived in phase 5. A coalescing or ternary result (second ?: other) is deferred the same way: it IS one of its operands; and so is a plain alias (alias <- second), which IS the object it names. The shapes are ObjectSharing.mayBeExistingObjectByShape(EK9Parser.ExpressionContext, Function); phase 5 judges them by ObjectSharing.mayBeExistingObject(EK9Parser.ExpressionContext, Function). Anything clearly fresh (a literal, a constructor, a constant, a declaration without an initialiser, a function reference) and anything re-pointed keeps today's verdict here.