Describe a value thrown out of a ShadowRealm without running any of its code

[lahma]

Follow-up to #4176.

The defect

ShadowRealm.prototype.evaluate copies a failure into a TypeError of the calling realm, and it built that copy's message with ToString of the thrown value (JsValue.ToString() → TypeConverter.ToString / Error.prototype.toString). That calls toString, @@toPrimitive, a name or message getter, and every proxy trap along the way. CreateTypeErrorCopy says of itself that it "must not cause any ECMAScript code execution", and the host-provided message is covered by that too.

These were measured on main at 7d9cdcc8f:

thrown inside the shadow realm	what reached the caller	shadow-realm code run
throw { toString() { ran++; return 'custom'; } }	TypeError: Cross-Realm Error: custom	1 call
throw { toString() { ran++; throw new RangeError('from toString'); } }	the shadow realm's RangeError, not a TypeError	1 call
an Error with a message getter	TypeError: Cross-Realm Error: Error: g	1 call
new Proxy(new Error('pe'), { get … })	TypeError: Cross-Realm Error: Error: pe	4 trap calls
new ShadowRealm().evaluate("throw new Error('boom')") in a shadow realm	Cross-Realm Error: TypeError: Cross-Realm Error: Error: boom	none

The second row also broke isolation: an object from the shadow realm crossed the callable boundary. The last row is the mark #4176 stopped repeating for WrappedFunction. It was still added once per level here, because this path formatted the error value (TypeError: Cross-Realm Error: …) rather than reusing a message.

test262 at the pinned SHA (7ab7fafa) doesn't cover any of this. built-ins/ShadowRealm/prototype/evaluate/errors-from-the-other-realm-is-wrapped-into-a-typeerror.js and its siblings only assert the constructor of what is thrown, and none of them throws a value with an observable toString, getter or trap.

The fix

CopiedErrorMessage builds the message without calling anything:

• A primitive is its own string form. A symbol uses its descriptive string, because ToString refuses symbols.
• An object with [[ErrorData]] (JsError or IErrorData, the same test as Error.isError) is rendered as the line Error.prototype.toString would produce. name and message come from ValueSlotReader.ErrorText, the console's call-free reader. It uses a value only when it is a data property holding a string, and it stops at an accessor or a proxy anywhere on the prototype walk.
• Any other object, including a proxy of anything, is described by kind alone: an object that is not an Error was thrown.
• An error that is itself a copy keeps its message as it is, so ThrowCrossRealmError marks a failure leaving nested realms once.

For an ordinary error or a primitive the message is the same as before (Cross-Realm Error: ReferenceError: aaa, Cross-Realm Error: 42), and tests pin that.

importValue: its rejection handler was %ThrowTypeError%. That runs nothing, but it reported a module that failed to evaluate with the strict-mode 'caller', 'callee', and 'arguments' properties may not be accessed… message. It is now the proposal's ImportValueError function (length 1, name "", in the caller's realm), which performs the same copy. The new anchor is registered in SpecAnchors.txt.

Tests

Jint.Tests/Runtime/ShadowRealmErrorCopyTests.cs, 26 cases:

• the two repros: toString is not called, and a throwing toString still yields the caller's TypeError
• @@toPrimitive and valueOf
• message and name getters, including a throwing getter and a getter on a subclass prototype
• a non-string message, and a proxy on the error's prototype chain
• thrown proxies of an object, an error and a function, with every trap counted
• nested evaluate two and three realms deep, marked once
• importValue of a module that throws an error, and of one that throws an object with a toString
• 8 rows pinning the unchanged message for ordinary errors and primitives

Fails before: on 7d9cdcc8f without the fix, 18 of the 26 fail. The 8 that pass are the rows that pin the unchanged message. For example: a throwing toString got not a TypeError of this realm|from toString|ran=1, and two realms deep got …Error: TypeError: Cross-Realm Error: Error: boom.

Passes after:

suite	net10.0	net472
Jint.Tests	12,802 total / 12,797 passed / 0 failed / 5 skipped	8,850 total / 8,844 passed / 0 failed / 6 skipped
Jint.Tests.PublicInterface	3,817 total / 3,796 passed / 0 failed / 21 skipped	3,024 total / 3,003 passed / 0 failed / 21 skipped
test262 (full)	102,740 total / 102,651 passed / 0 failed / 89 skipped (control on main: 102,651 / 0 / 89)	—

Base: 7d9cdcc8fa1179b8ea92db17f617f6154dc56b7e (upstream main). Immediately before opening this, upstream was fetched again and the branch rebased onto it. The rebase was a no-op, so the full runs above are on the pushed commit. The ShadowRealm, spec-citation and error-message fixtures were run once more after the rebase, on both frameworks, and all passed.

Not changed here

WrappedFunction's [[Call]] and WrappedFunctionCreate still copy JavaScriptException.Message. That message is built when the throw leaves a function body, through [[Get]] of message. So the getter has already run by the time the copy is made, and it runs outside ShadowRealm too. Measured on main with plain script:

function f() { throw errorWithMessageGetter; }
try { f(); } catch {}

This runs the getter twice (and throw new Proxy({}, { get }) fires the get trap twice). That's an engine-wide defect with its own fix. Once it's fixed, the two wrapped-function sites can derive their message from ex.Error through CopiedErrorMessage, and then the copy will read the same whichever path it crossed.

🤖 Generated with Claude Code