Class ArgumentLabelling

java.lang.Object
org.ek9lang.compiler.repair.ArgumentLabelling
public final class ArgumentLabelling extends Object
THE labelling of a call's positional arguments from the parameter names the compiler resolved - use this, do not split an argument list by hand anywhere else.

Why this is a correction and not an inference. EK9 labels are positional documentation, not a reordering mechanism: ValidNamedArgumentsOrError compares the label at index i with parameters.get(i).getName() and errors if they differ, so a label can never change which method resolves - resolution happened earlier, by type and position. The names come off the RESOLVED method, attached to the diagnostic by AmbiguousCallArgumentsOrError (ErrorDetails.getDeclaredParameterNames()). So for E11062 (4+ arguments must be named) and E11061 (2+ literal true/false must be) there is exactly one legal spelling of the call the caller already wrote, and this produces it.

Refuses rather than guesses. Returns null - leaving the caller's refusal intact - whenever the rewrite is not certain: the argument count does not match the parameter count, any argument is already labelled, the list is unbalanced, or the call does not close on its own line. A multi-line call is deliberately out of scope; every occurrence measured on the harness was one line, and a partial rewrite of a wrapped call would be worse than a refusal.

  • Nested Class Summary

    Nested Classes
    Modifier and Type
    Class
    Description
    static final record 
    ArgumentLabelling.Result
    The corrected text plus one note per call labelled; notes empty means nothing moved.

  • Method Summary

    Modifier and Type
    Method
    Description
    static String
    labelled(String line, int openParenColumn, List<String> names)
    Label the call whose opening parenthesis is at openParenColumn (0-based, as a diagnostic reports it) on line.
    static boolean
    mayNeedLabels(String text)
    A cheap textual pre-filter: could this text contain a call the language will make us label - one with four or more arguments, or two or more literal true/false? Purely to keep the happy path free of an extra compile; a false positive costs one, a false negative only leaves the refusal as it is today.
    static ArgumentLabelling.Result
    repair(String text, List<Map<String,Object>> diagnostics)
    Label every call in text that a would-fail diagnostic says needs it.

    Methods inherited from class Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Method Details

    • repair

      public static ArgumentLabelling.Result repair(String text, List<Map<String,Object>> diagnostics)
      Label every call in text that a would-fail diagnostic says needs it. Driven ENTIRELY by the diagnostics: each must be E11061 or E11062 and carry the parameterNames the compiler resolved, and its line and column say exactly which call. A diagnostic this cannot act on with certainty is skipped, so the caller's refusal survives for that one.
      Parameters:
      diagnostics - the ยง1.1 wire-shape diagnostics, as wouldBeDiagnostics carries them

    • mayNeedLabels

      public static boolean mayNeedLabels(String text)
      A cheap textual pre-filter: could this text contain a call the language will make us label - one with four or more arguments, or two or more literal true/false? Purely to keep the happy path free of an extra compile; a false positive costs one, a false negative only leaves the refusal as it is today. Never treats this as an answer - only the compiler decides.

    • labelled

      public static String labelled(String line, int openParenColumn, List<String> names)
      Label the call whose opening parenthesis is at openParenColumn (0-based, as a diagnostic reports it) on line.
      Returns:
      the rewritten line, or null when the rewrite is not certain