Test262: fromCodePoint surrogates (#108), call arg-order (#106), Object.create proto + isPrototypeOf (#104)

[nickna]

Addresses Test262 issues #104, #105, #106, #108, #112. A recurring theme: most were substantially stale — intervening main work had already resolved much of each — so every issue was re-measured against the live baseline before acting.

What changed

#108 — String.fromCodePoint lone surrogates (fixed, both modes)

char.ConvertFromUtf32 throws on lone surrogates (0xD800–0xDFFF), but they are valid code points for fromCodePoint. Implemented ECMA-262 §11.1.3 UTF16EncodeCodePoint (cp <= 0xFFFF → single code unit incl. lone surrogates; else surrogate pair) in both the interpreter (StringBuiltIns.AppendCodePoint) and compiled (RuntimeEmitter.EmitStringFromCodePoint), and added the §22.1.2.2 integral check to the interpreter. Clears every RuntimeError in RegExp/CharacterClassEscapes/.

#106 — argument evaluation order vs. callability (fixed, compiled)

Per §13.3.2.1/§13.3.6.1, evaluating a member-access callee recv.method runs RequireObjectCoercible(recv) before ArgumentListEvaluation — so o.bar.gar(foo()) with o.bar undefined must throw TypeError before foo() runs. Compiled mode deferred the throw past the args. Added EmitThrowIfReceiverUndefined on the method-call path. It guards on $Undefined only (not bare null): compiled sloppy-mode this is represented as null and must stay coercible, so this.bar(foo()) still evaluates its args (this caught a 11.2.3-3_8 regression during development).

#104 — Object.create (interpreter parity, partial)

The interpreter lagged compiled badly. Two fixes: (1) validate the prototype argument (§20.1.2.2 step 1) and throw a real SharpTSTypeError for a non-Object/non-null proto — crucially via ThrowException(new SharpTSTypeError(...)), not new Exception("TypeError: …"), so assert.throws(TypeError, …)/instanceof see an Error instance (see #694); (2) Object.prototype.isPrototypeOf was a stub returning false — implemented the §20.1.3.4 chain walk. The titled core (iterating built-in property bags with accessors) needs accessor storage on Math/JSON/Date/Error/wrappers — a larger multi-type feature, scoped out and documented on #104.

#105 — built-in method .length + receiver guards (already satisfied)

Confirmed both modes already meet the spec (landed with #101). Added a regression suite (BuiltInMethodLengthAndReceiverTests) since the Test262 project isn't part of dotnet test.

#112 — RegExp Symbol.* edge cases (not fixed, triaged)

All 7 require infrastructure beyond focused scope: surrogate-aware unicode matching (overlaps #693), sloppy-this=globalThis binding, cross-realm $262.createRealm (no realm model — out of scope), and built-in-constructor property assignment (Array.print = print blocks coerce-global). Full per-cluster root-cause analysis posted to #112.

New issues filed

• RegExp: \w/\s/\W/\S ECMAScript shorthand classes diverge from JS (.NET engine quirks) #693 — \w/\s ECMAScript shorthand classes diverge from JS (.NET \w matches U+0130, \s misses Unicode whitespace). This is why 4 CharacterClassEscapes tests still fail.
• Interpreter: built-in 'TypeError:'/'RangeError:' exceptions caught as plain strings, not Error instances #694 — interpreter built-ins throw new Exception("TypeError: …") which is caught as a plain string, not an Error instance (compiled mode is correct).

Tests / verification

• Full unit suite: 12,740 pass, 0 regressions. Added regression tests for each fix (StringMethodTests, NonCallableInvocationTests, ObjectCreateTests, ObjectPrototypeTests, BuiltInMethodLengthAndReceiverTests).

Reviewer notes — Test262 baselines

The committed baseline changes are deliberately scoped to the folders these fixes deterministically affect (Object/create, RegExp/CharacterClassEscapes, the expressions/call/11.2.3-3 family): interpreted +45 lines, compiled +13 lines, all sensible transitions, no Pass → non-Pass regressions. A full regen surfaced large pre-existing drift (recent main work the stale baseline never captured) plus parallel-execution flakiness in unrelated paths; including that would muddy the diff and commit flaky values, so it's left for a maintainer full regen. No CI workflow runs the Test262 conformance suite, so this doesn't gate the PR.