Class LockedItemExposureOrError

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.common.TypedSymbolAccess
org.ek9lang.compiler.phase3.LockedItemExposureOrError
All Implemented Interfaces:
Consumer<EK9Parser.AssignmentStatementContext>
final class LockedItemExposureOrError extends TypedSymbolAccess implements Consumer<EK9Parser.AssignmentStatementContext>
Outbound-encapsulation check: data inside a MutexLock must be purely contained — the lock holds the only reference to its protected payload. Reference-assignment of lockedItem (inside a MutexKey body) to ANY target creates a second reference and exposes the payload, defeating the lock's exclusivity guarantee.

Detection: when an assignment statement is processed, check whether the enclosing function is a MutexKey of T body (via supertype check). If yes and the operator is alias-creating (:=, =, :, :=?) AND the RHS resolves to the body's lockedItem parameter, emit E08258.

In-place mutation operators (:=:, :~:, :^:) are NOT alias-creating and are permitted — they update the locked value without creating a new reference to it.

Slice-1 conservative rule: only direct lockedItem references are checked. Derived expressions (lockedItem.field, indexed access, pure-method results) are deferred to slice 1.5 if real corpus surfaces friction.

Part of EK9's compile-time data-race detection (slice 1, model rule §2.7). Error E08258 MUTEX_LOCK_PAYLOAD_EXPOSED.