Class DispatcherHandlerInTraitOrError

All Implemented Interfaces:
BiConsumer<EK9Parser.TraitsListContext, AggregateWithTraitsSymbol>

final class DispatcherHandlerInTraitOrError extends TypedSymbolAccess implements BiConsumer<EK9Parser.TraitsListContext, AggregateWithTraitsSymbol>
A trait may not supply a dispatcher handler (E07825, front-end rationalisation D21, Steve 2026-10-20): a dispatcher and every one of its handlers live in one class hierarchy. Symmetrical with E07810, which keeps the entry point itself out of a trait.

A handler is what DispatcherHandlers.collectFor(IAggregateSymbol, MethodSymbol) says competes for an entry point of the class (the same name and arity, not abstract, not overridden by a more-derived declaration); the entry points are DispatcherHandlers.entryPointsOf(IAggregateSymbol) - declared on the class or inherited from a super, never the aggregate's dispatcher MARKER, which is also true for an ordinary class with an argument-taking operator. Any such handler declared in a trait is the error. So a trait declaring the entry point abstractly is not a handler, and neither is a trait method the class overrides with its own handler.

One error per class per dispatcher, reported where the trait is listed: on the class's own trait reference that leads to the trait (directly, or through a trait listed by that trait), so an @Error directive can pin it; or on the class itself when the trait comes only through a super class that does not declare the dispatcher. A handler the super class already reports (it has the same dispatcher and the same trait handler) is not reported again on each sub-type.

Run in FULL_RESOLUTION on the exit of a class (and a dynamic class) declaration, beside the other dispatcher checks (ValidDispatcherMethodsOrError): supers and traits are linked by then, the synthesised entry point of an inherited dispatcher (InheritedDispatcher, end of phase 2) exists, and a trait listed by a delegate has its forwarding methods (which are the class's own) added on entry.