Class CompilerPlumbingCalls

java.lang.Object
org.ek9lang.compiler.phase7.support.CompilerPlumbingCalls
All Implemented Interfaces:
BiPredicate<String,String>
public final class CompilerPlumbingCalls extends Object implements BiPredicate<String,String>
THE definition of which callees are compiler↔runtime PLUMBING rather than part of the EK9 program. Ask this (hold one: test(targetTypeName, methodName)) 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.

The one-question siblings

IsBoundaryPrimitive and IsCompilerOnlyConstruction are two of the three kinds asked on their own; RunsNoEk9Code is the narrower question V-I asks; IsSynthesisedMember is THE set of symbol-less members the compiler synthesises (not plumbing, but likewise carrying no metadata clause).

  • Constructor Details

    • CompilerPlumbingCalls

      public CompilerPlumbingCalls()

  • Method Details

    • test

      public boolean test(String targetTypeName, String methodName)
      Is this callee compiler plumbing, and therefore outside the measured domain entirely?
      Specified by:
      test in interface BiPredicate<String,String>
      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