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.

Three 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.
  • Compiler-only construction - the constructor of a real EK9 type that EK9 code may observe but never create. The type resolves; its constructors carry no @Ek9Constructor, so they are absent from the EK9 surface. Panic is the one case (Steve, decision 10, 2026-10-05): only the compiler raises a Panic (PanicThrowInstrs).

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

    • isCompilerOnlyConstruction

      public static boolean isCompilerOnlyConstruction(String targetTypeName, String methodName)
      A constructor of a type that only the compiler may create - Panic.<init>.

    • 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.

    • isSynthesisedMember

      public static boolean isSynthesisedMember(String methodName)
      THE compiler-synthesised MEMBER set - _i_init, _c_init, _fieldSetStatus, _copyAccepts (Steve, F3a 2026-10-08: one predicate, widened from the lifecycle pair).

      NOT plumbing: each has a real body in the IR of the same construct (the field initialisers the user wrote, the generated field-status bitmap, the generated copy check), so an IR reader resolves the call to that body. They are listed here because, like plumbing, they have no symbol and phase 5 never measures them, so their CALL carries no metadata clause - and is CallDetails.Kind.SYNTHESISED_MEMBER, never UNRESOLVED.

      Matching by name is sound because a user cannot declare a method of any of these names: a leading _ cannot start an EK9 identifier, and none of them is ever defined into a symbol table (no symbol is the definition - that is what puts them here). (_i_init/_c_init were i_init/c_init until 2026-09-25, which a user COULD write - see docs/implementation/EK9_LIFECYCLE_METHOD_RENAME_PLAN.md.) A new compiler-synthesised member with no symbol joins this set, never a second list.