Class StreamAppendsToItsSourceOrError

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.common.TypedSymbolAccess
org.ek9lang.compiler.phase5.StreamAppendsToItsSourceOrError
final class StreamAppendsToItsSourceOrError extends TypedSymbolAccess
THE check that a stream statement never appends to the very variable it is reading (E08277, Steve 2026-10-21, D82; widened to EVERY type 2026-10-26, Q6/Q8 - one rule, no type list): cat items >> items appends to items while cat is still pulling from it - the pull never reaches the end, and at run time the List's iterator says so. GNU cat's "input file is output file".

The same variable - by SYMBOL identity, never by name - is both a cat source and an appending target of ONE stream statement: the >> termination, or a tee stage whose target it is (a tee appends each element as it passes). A variable is only judged where it is written as the object's own: a local, a parameter, a bare property, or this.property; other.items is another object's variable (same property symbol, another object) and is never the same. A property reached two ways (this.items and bare items) is the same symbol and IS reported.

The target's type is NOT asked: a List, a Set, a Dict, a PriorityQueue, a JSON or anything else is reported. > is never reported - into a collection it fills a fresh one and swaps it in when the pipeline completes (StreamStages.replacesTargetOnCompletion(int, Ek9Types, ISymbol)). An alias (other <- items) is a different symbol and cannot be seen here - the runtime checks (a List's "changed while it was being read", a JSON's) remain the backstop.