Class UninitialisedReturn

java.lang.Object
org.ek9lang.compiler.repair.UninitialisedReturn

public final class UninitialisedReturn extends Object
THE E08180 repair on a RETURN declaration - <- rtn as String with neither a value nor ? - for every editing tool. Use this; do not re-derive the shape or the rule.

A return declared with neither never compiles: phase 1 raises E08180 on it (ProcessVariableOnlyOrError.checkReturningParam, the only rule that can, for a <- line). With ? it is the declaration EK9 expects - declared here, assigned on every path below - and the flow check then proves every path assigns it (E08050 when one does not). So the rewrite cannot change which code runs: the original never runs at all. A property or a local is NOT repaired here - there ! (injection) and an initial value are further readings.

Measured (cycles 8-12): 5 would-fails on modify T10, all Qwen3.8. One run sent the correct if/else chain twice, blocked only by this, then abandoned it for switch variants and failed.

  • Field Details

    • SHAPE

      static final Pattern SHAPE
      <- name as Type with nothing after the type.
  • Method Details

    • mayApply

      public static boolean mayApply(String text)
      True when text has a return declaration of the shape at all - the cheap gate before a probe compile.
    • repair

      public static UninitialisedReturn.Result repair(String text, List<Map<String,Object>> diagnostics)
      Add the ? to every return declaration an E08180 diagnostic sits on. Driven entirely by the diagnostics: the code must be E08180 and its line and column must sit exactly on the NAME of a <- name as Type line. Anything less certain is skipped and the caller's refusal stands for it. Rewrites within one line, so the receipts can follow (SourceRepairs).