[ASDAlexander77]

Fixes #342. A method with a written this: parameter carried its receiver twice in its signature:

class O {
    x = 1;
    m(this: O, a: number, b: number) { return a + b + this.x; }
}
new O().m(1, 2);   // error: Expected 3 arguments, but got 2.

The signature came out as !ts.func<!ts.class<@O>, !ts.class<@O>, number, number, number>.

Cause

mlirGenParameters first adds the implicit receiver. That is an opaque this for an interface method, and genContext.thisType for a class method, an object-literal method, or a function expression with a thisType. The loop over the written parameters then treated this like any other parameter and added a second slot.

Fix

When the parameter list already starts with the implicit receiver, the written this is skipped. The receiver keeps its implicit type, and the annotation does not replace it:

• An interface method keeps the opaque receiver its vtable call expects.
• An object-literal method keeps the literal's own layout, not the looser { x: number } it was annotated with.
• A class method annotated with an interface type (this: I) still gets the class.

Free and extension functions have no implicit receiver, so their written this is still the receiver they bind. That path is unchanged, and it covers every this: in TypeScriptCompilerDefaultLib.

Tests

• New 00method_this_param.ts (compile, jit, and the rc/none corpus). It covers a class method, an interface method implemented by a class and called through the interface, an object-literal method, and an extension function as a control.
• New call-arity/method_this.ts: a short call now reports Expected 2 arguments, but got 1. It used to say "3 … got 1".
• Full release suite: 2969/2969 passed.

Not in this PR

• getSignature (MLIRGenTypes.cpp), which builds type-literal and function-type signatures, still keeps a written this as an ordinary parameter.
• The commented-out static-class extension method in 00lambdas.ts is a different feature and stays commented out.

🤖 Generated with Claude Code