Class ResolverOrDefiner

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.support.ResolverOrDefiner
Direct Known Subclasses:
ParameterisedLocator, ResolveOrDefineTypes
public abstract class ResolverOrDefiner extends RuleSupport
Used as an abstract base for parameterised types.

  • Field Details

    • symbolFactory

      protected final SymbolFactory symbolFactory

    • errorIfNotDefinedOrResolved

      protected final boolean errorIfNotDefinedOrResolved

    • checkSemanticConstraints

      protected final boolean checkSemanticConstraints

  • Constructor Details

    • ResolverOrDefiner

      protected ResolverOrDefiner(SymbolsAndScopes symbolsAndScopes, SymbolFactory symbolFactory, ErrorListener errorListener, boolean errorIfNotDefinedOrResolved)

    • ResolverOrDefiner

      protected ResolverOrDefiner(SymbolsAndScopes symbolsAndScopes, SymbolFactory symbolFactory, ErrorListener errorListener, boolean errorIfNotDefinedOrResolved, boolean checkSemanticConstraints)
      Parameters:
      checkSemanticConstraints - when true (the default for user-source resolution paths), additional EK9 semantic constraints are enforced at parameterisation time — currently the rules that MutexLock (or a parameterised MutexLock of T) cannot appear as a type argument to another generic (E08254), and that Void cannot be a type argument at all (E10011, reported once types are resolved, from phase 2; see VoidAsTypeOrError). Internal compiler synthesis paths (e.g. SynthesizeSuperFunction) pass false to skip these user-facing rules. The closeable rule (E81061, from phase 2; see CloseableNotInGenericParameterOrError) is NOT one of them: it holds on every path that reports, synthesis included - synthesis declines to name a closeable instead (D7, 2026-10-06).

  • Method Details

    • resolveOrDefine

      public Optional<ISymbol> resolveOrDefine(ParameterisedTypeData details)
      Attempts to resolve the parameterised type first and return that, else returns a new symbol.