Test262 #6: Built-in method values lack .length property and receiver-type guards (~65 tests)

[nickna]

Motivation

Surfaced during the #69 RegExp folder rollout (commit b968a9e). Built-in prototype methods (RegExp.prototype.exec, RegExp.prototype.test, etc.) are missing two spec-required behaviors:

1. .length is not exposed. RegExp.prototype.exec.length === 1 should be true. We return undefined (or throw).
2. Receiver-type checks missing. RegExp.prototype.exec.call({}, "...") should TypeError because {} isn't a RegExp. We silently proceed and return wrong values.

Both stem from the same architectural shape: BuiltInMethod / TSFunction instances representing prototype methods don't expose the Function.prototype properties (name, length) the spec mandates, and don't validate this against the expected internal slot.

Sample failing tests

• test/built-ins/RegExp/prototype/exec/S15.10.6.2_A11.js:

  assert.sameValue(RegExp.prototype.exec.hasOwnProperty("length"), true);
  assert.sameValue(RegExp.prototype.exec.length, 1);   // RuntimeError: undefined

• test/built-ins/RegExp/prototype/exec/S15.10.6.2_A2_T1.js:

  var __instance = new Object;
  __instance.exec = RegExp.prototype.exec;
  __instance.exec("...");   // should TypeError; we return null/garbage

Impact

Cluster	Count
RegExp.prototype.exec length / receiver	21 (interp) + 21 (compile)
RegExp.prototype.test length / receiver	18 (interp) + 16 (compile)
(Same pattern likely affects String.prototype.*, Array.prototype.*, etc., across the whole baseline)	unknown but large

The 65-test count above is just RegExp; the length issue is cross-cutting — every built-in method instance in SharpTS is affected.

Suggested approach

1. Wire .length on built-in methods. BuiltInMethod (Runtime/BuiltIns/BuiltInMethod.cs) and TSFunction (compile mode) should expose .length reflecting the formal parameter count of the underlying delegate. Same place that exposes .name should expose .length.
2. Add receiver-type checks to RegExp prototype methods. Each method validates this has the [[RegExpMatcher]] internal slot before proceeding; throw TypeError otherwise. The interpreter's Runtime/Types/SharpTSRegExp.cs and compile-mode's RuntimeEmitter.RegExp.cs (or wherever the dispatch lives) need this guard.
3. Generalize the receiver check to a cross-cutting helper so the same pattern can be applied to Array.prototype.*, Map.prototype.*, etc. as those gaps surface.

Acceptance

• RegExp.prototype.exec.length === 1 and the same for test.
• RegExp.prototype.exec.call({}, "...") throws TypeError.
• The ~65 RegExp tests above flip out of RuntimeError/Fail.
• Sanity-check: String.prototype.charAt.length, Array.prototype.push.length, Function.prototype.call.length all return correct values (these may already work — verify).

Related

Part of #69. Likely a foundational fix that unblocks more of #103 and beyond.

[nickna]

Deferred — JS (Test262) conformance track de-prioritized.

SharpTS's core goal is TypeScript language compatibility first. The Test262 / ECMA-262 runtime-conformance work has diminishing returns for that goal, so this issue is being set aside (label: deferred). It is not closed — it remains a valid, tracked item and can be reactivated if priorities change.

Active focus moves to the TypeScript conformance track (#80 and children) and genuine correctness bugs.