Class DispatcherHandlerReachabilityOrError

java.lang.Object
org.ek9lang.compiler.phase5.DispatcherHandlerReachabilityOrError
final class DispatcherHandlerReachabilityOrError extends Object
Reports a dispatcher handler whose parameter type has no concrete form anywhere in the program, so no value can ever have that runtime type and the handler is dead code that looks live.

Why this cannot be left to the reader. Reachability is not a local property of the dispatcher: it depends on which types elsewhere in the program extend or implement the handler's parameter type. Delete the last class implementing a trait, drop an extends during a refactor, or narrow a hierarchy, and a handler in a file you never opened becomes unreachable - still compiling, still looking live, silently never called.

Deliberately narrower than "never wins". An earlier draft reported any handler that no concrete type selects. That double-reported with DispatcherTypeHierarchyOrError (E05210) and, worse, misdiagnosed it: for a handler whose type is concrete but simply not under the base, E05210 names the real fault and this check would have blamed "nothing extends it" - which is false. So this asks only the question E05210 cannot: does the handler's type have any concrete form at all? A concrete handler type always passes here and is E05210's business; only an abstract class, trait or abstract function with no implementor is reported.

The set it consults is phase 7's. isMarkedAbstract plus ConcreteSubtypeFinder is exactly how DispatcherReachableTypes.concrete decides what phase 7 emits dispatch entries for, so if this fires, phase 7 would emit no entry for that handler. That includes dynamic constructs: a dynamic function conforming to Consumer of Integer is a concrete sub-function and makes such a handler reachable.