Class CompilerPlumbingCalls

java.lang.Object
org.ek9lang.compiler.phase7.support.CompilerPlumbingCalls
public final class CompilerPlumbingCalls extends Object
THE definition of which callees are compiler↔runtime PLUMBING rather than part of the EK9 program. Ask this before deciding whether a synthesised CALL should carry call metadata.

The distinction is not "we found a symbol" versus "we failed to". It is PROGRAM versus PLUMBING. Call metadata (purity, complexity, side-effects) is a property of the callee that somebody authored: a user wrote as pure, phase 5 measured complexity from their code, and an AI can change either by editing source. For the callees listed here nobody authored anything - they are artefacts of the compiler's own lowering, and no edit by any user or AI can affect them. Recording a program-property field against one is a category error, not a missing measurement, which is why these sites emit no metadata clause at all rather than a default or "unresolved" tuple.

Matching is by NAME, and that is correct here rather than the usual FQN-string-matching anti-pattern: having no symbol to match against is the very definition of this set. Everything with a symbol goes through SynthesisedCallMetaData instead.

Two disjoint kinds

  • Boundary primitives - methods on real EK9 types that cross the EK9/host boundary. Their target TYPE resolves; the METHOD does not. They are declared in ek9-lang's Java sources under the comment "Useful external methods, for use with IR and code generation", with no @Ek9Method annotation, so they are absent from the EK9 surface and from every symbol table. This is the trap in the original Root C triage: because the type resolves, they were counted as fixable sites.
  • Runtime helper types - whole types backing the stream lowering (Ek9Sort, Ek9Async, ...). None carries @Ek9Class, so neither the type nor its methods exist as symbols.

Relationship to the JVM back-end's list

backend.jvm.CallInstrAsmGenerator.isJavaPrimitiveBooleanMethod enumerates _true, _false, _set, isNew, isFirst, hasResult, isKeyChanged, wasStarted, hasNextGroup. That is a strict SUBSET of this surface, selected by a different question - "does it return a Java primitive boolean" - so the two lists must NOT simply be merged: _of, _ofTrue and _ofFalse are plumbing yet return an EK9 Boolean, and so are deliberately absent there. If the back-end's list is ever hoisted, hoist it as a distinct predicate over this same surface.

  • Method Details

    • isPlumbing

      public static boolean isPlumbing(String targetTypeName, String methodName)
      Is this callee compiler plumbing, and therefore outside the measured domain entirely?
      Parameters:
      targetTypeName - the FQN of the type the call is made on (nullable for a static call)
      methodName - the method being called
      Returns:
      true when the CALL must carry NO metadata clause

    • isBoundaryPrimitive

      public static boolean isBoundaryPrimitive(String methodName)
      A method on a real EK9 type that has no EK9 symbol - _true, _ofFalse, ...

    • isHelperType

      public static boolean isHelperType(String targetTypeName)
      A stream-lowering runtime helper type, none of whose members are symbols.