Test262 #8: eval(...) rejected in property-accessors and elsewhere (~10+ tests, broader impact)

[nickna]

Motivation

Surfaced during the #69 property-accessors rollout (commit 2f92515). Test262 uses eval("…") to verify parser-level whitespace tolerance:

if (eval("Number	.	POSITIVE_INFINITY") !== Number.POSITIVE_INFINITY) {
  throw new Test262Error('...');
}

In SharpTS this buckets as TypeCheckError, suggesting our type checker either:

1. Doesn't have eval typed in lib.d.ts.
2. Special-cases eval and rejects it under TS strict.
3. Treats the return as something other than any, causing the !== comparison to fail type-check.

Sample failing tests

test/language/expressions/property-accessors/S11.2.1_A1.1.js and siblings (~10 tests in property-accessors).

eval also lurks in many other Test262 directories we haven't yet rolled out; addressing this now lifts a categorical floor before those rollouts.

Impact

Folder	Tests using eval()
language/expressions/property-accessors	~10
language/expressions/{this, comma, ...} (not yet rolled out)	unknown
language/statements/{block, with, ...} (not yet rolled out)	unknown

The PA hit alone is small; the cross-cutting impact on future rollouts (priority-2/3 folders in #69) is much larger.

Suggested approach

Two open questions to investigate:

1. Is eval parsed and typed at all? Spot-check Parsing/Parser.*.cs and TypeSystem/* — search for "eval" references. If eval is special-cased to reject, lift the rejection in non-strict-mode contexts at minimum.
2. Does SharpTS support eval at runtime? True dynamic eval requires re-running the parser/type-checker/interpreter against a string. Compile mode is harder (eval would need JIT). If we don't and won't support runtime eval:
   • Type the global eval as (s: string) => any so calls type-check and run as a no-op stub returning undefined.
   • That makes Test262 tests fail at runtime with a deterministic outcome (RuntimeError "eval not supported") rather than TypeCheckError, surfacing the gap.

Decision: do we support eval at all? If not, the lib.d.ts stub is the right fix.

Acceptance

• The ~10 property-accessor tests using eval() move from TypeCheckError to either Pass (if eval works) or RuntimeError: eval not supported (if we choose the stub route).
• A clear documented stance on eval() in CLAUDE.md / STATUS.md so future rollouts don't re-investigate this.

Related

Part of #69. Pre-condition for cleaner rollouts of language/expressions/{this, comma, ...} and language/statements/* (priority-2/3 in #69).