[LPTK]

[GPT-6 Astra and Claude Opus 5.5, with some manual updates]

Previously: Overrides could change which arguments reach their parameters or lose representations declared by a base method. A valid call through the base could then fail at runtime, and direct and virtual Wasm calls could disagree about their signature.

In this PR: Validate the source override contracts and check Wasm's additional calling-convention restrictions.

Unannotated override parameters and results inherit the base member's representations. In this example, Child.take keeps Int32 for both its input and result, and the direct and virtual calls together return 42 on Wasm:

abstract class Base() with
  fun take(value: Int32): Int32
class Child() extends Base() with
  override fun take(value) = value
fun dispatch(receiver: Base, value: Int32): Int32 = receiver.take(value)
wasm.i32.add(dispatch(Child(), wasm.i32.const(40)), Child().take(wasm.i32.const(2)))

Explicit annotations must accept the inherited input representations and produce results that fit the inherited result representation. JavaScript permits wider accepted inputs. Wasm also checks the reverse direction: widening a base parameter from Int to Any is rejected because direct calls of the override still use the base method's physical slot. Method bodies use that shared physical signature for their parameter slots and declared result, including abstract declarations and narrowed reference results. Returned values are not downcast to the slot: a mismatch that lowering did not coerce remains a compilation error.

Source layout checks reject changes that redistribute inherited arguments, even for unused or abstract members:

private class RestBase() with
  open fun collect(...values: Array[Any]): Any = values
private class StolenRest() extends RestBase() with
  override fun collect(first?: Any, ...values: Array[Any]): Any = values

For a call such as collect(1, 2), the added first parameter would change the inherited rest binding from [1, 2] to [2]. The compiler now reports that the override must preserve the arguments bound to inherited parameter values. Renaming parameters and adding an optional suffix remain valid when every permitted base call preserves its bindings (Wasm additionally requires an override to keep the introducing method's number of parameters). An inherited drop parameter may be omitted only when the remaining bindings stay intact.

Because overrides inherit these representations, an overridable member (open or abstract) of an open or abstract class, or of an open object, must specify its parameter and result types when its compilation unit exposes it, that is, when the resolver's interface-exposure probes reach it from the unit's exports. A type can come from an annotation, a separate full signature, or the corresponding part of an overridden member's signature, which overrides inherit unchanged:

open class Typed() with
  open fun scale(x: Int, y: Int): Int = x * y
open class Inheriting() extends Typed() with
  open override fun scale(x, y) = x + y            // inherits (Int, Int) -> Int
open class Extended() extends Typed() with
  open override fun scale(x, y, factor?) = x * y   // error: 'factor' has no type to inherit

Other members, including those of private and local classes, are overridden only within their own unit and need no annotations. Marking a private member open produces a warning, since private members are never overridden.

The implementation also:

• Checks optional, rest, trailing, curried, and contextual parameter layouts. Unsupported callable layouts receive a diagnostic.
• Preserves omitted arguments through ordinary call lowering so each callee binds its own defaults.
• Adds collection regressions for the iterable implementations on hkmc2, covering omitted slice bounds and zero or multiple concatenation arguments through direct and base-class calls.
• Reports a failure in the inherited declaration's layout at the override, naming the overridden member, and skips layout checks for overrides already rejected for changing member kind.
• Caches each declaration's override layout and indexes validated override edges by overriding member.
• Documents the override contract and includes the updated inline golden outputs.
• Notes in AGENTS.md that the legacy resolver is being sunset; legacy-only issues found in review are left unfixed.

This combines E14 from #575 with the override-specific work from LPTK/proper-overriding-checks. The Scala diff against hkmc2 is +903 / -124 lines (git diff --shortstat, documentation comments included).

Known open item: the Wasm backend's override-slot check and the source override checks still report some mismatches twice. (See below.)

[LPTK]

[Claude Opus 5.5] Review of the override binding and representation checks; details are inline.

Two issues are deliberately left out: the Wasm rejection of overrides that make a required boxed parameter optional (intended, since Int will compile to a non-nullable slot) and an issue specific to legacy resolution (the legacy resolver is being sunset). Regression tests are in 5842e11.

[LPTK]

[Claude Opus 5.5] Wasm override constraints are now enforced in three places that overlap: OverrideChecks (source representations), this widening check, and WatBuilder.checkOverrideSignature (primitive slot equality and arity). The same mismatch is reported twice, once in erased-type terms and once in Wasm-type terms. See the M2 and N2 blocks in wasm/VirtualMethods.mls, e.g. "Parameter 'm' … is represented as 'Int' …" followed by "Overriding method g declares parameter 1 as (ref null i31), but the method it overrides declares i32".

[LPTK]

[Claude Opus 5.5] Not resolved yet.

Any ErrorReport raised during WatBuilder's predeclaration phase breaks out of module generation. So checkOverrideSignature is also what stops body generation for a slot it cannot represent. When I suppressed its primitive checks for members that have a source override edge, codegen continued into the bodies of wasm/VirtualMethods.mls (M2) and crashed in castConserve (require(expr.resultTypes.size == 1)).

Resolving this needs a way for WatBuilder to stop generating a module without raising its own diagnostic, such as an aborted status on CompiledWasmModule that the diff harness honors. That is a backend API decision, so I left both diagnostics in place for now.

[LPTK]

For the record, the proper fix will be to treat those backend errors that refer to internal implemnetation details (such as WASM types) as internal errors, and make sure that they do not actually reach the backend (aborting compilation of that particular definition early on).

This will be done in a separate PR.

[LPTK]

[Claude Opus 5.5] About 02ce875, refined by 0b4321a and 9861609

Why. This PR makes unannotated overrides inherit their bases' parameter and result representations. When the base is itself unannotated, there is nothing to inherit. For example, an exposed open fun f(x) = x + 1 would give every override in another compilation unit unknown representations, and erasure in that unit cannot recover the types. So members that other units can override must specify their signatures.

The rule. The compiler reports an error for an overridable member (open, or abstract) of an open or abstract class, or of an open object, when both of these hold:

• The member is exposed: InterfaceExposure's unknown-shape probes reach it from the unit's exports. These are an imported module's exports, or every public top-level definition under strict resolution.
• One of its parameters or its result is unspecified.

A type is specified by any of:

• an annotation;
• a separate full signature;
• inheritance from the corresponding part of a specified overridden signature, which overrides reuse unchanged without refining it.

Overridden members of other compilation units count as specified, because their own unit enforces the rule.

open class Typed() with
  open fun scale(x: Int, y: Int): Int = x * y
open class Inheriting() extends Typed() with
  open override fun scale(x, y) = x + y            // OK: inherits (Int, Int) -> Int
open class Extended() extends Typed() with
  open override fun scale(x, y, factor?) = x * y   // error: 'factor' has no type to inherit

Exempt:

• members of classes that are neither open nor abstract, and of non-open objects, since other units cannot extend them;
• members of private and local classes;
• private members. Marking a private member open now produces a warning (9861609).

Implementation. InterfaceExposure.recordOpenMember records each such member, with the path that exposed it, in NewResolverState.exposedOpenMembers. During erasure, OverrideChecks.checkExposedSignatures follows the override layouts to find the parameters that inherit a specified type. It reports the rest, using the exposure path as notes. The first version (02ce875) checked written annotations directly in InterfaceExposure. 0b4321a moved the check into erasure, because recognizing inherited signatures needs the parameter correspondence computed there.

Fallout:

• compile-test modules: ObjectBuffer.buf: Any and SealedClasses.Abstract.value(): Int;
• annotations on abstract classes in newres/Overrides.mls and newres/wasm/Super.mls, and on open class Parent in slop/strictres/IterableSpreads.mls;
• the effect class in newres/HandlerResults.mls is now private.

The rule is covered by slop/strictres/ExposedOpenSignatures.mls.

Choices worth a second look:

• Abstract members count as overridable.
• The open members of an open object are checked, although objects cannot be extended yet.
• A member defined in one worksheet block but first exposed by a later block is not checked: each block is erased before later blocks run their exposure pass. Under strict resolution, every public top-level definition is exposed by its own block, so this affects only classes that first escape through a later block.

[LPTK]

LGTM now.