runtime: Number/Boolean/Symbol/BigInt prototype methods don't brand-check this (reflective call returns [object Object] instead of TypeError) (#3662)

Part of the #3662 cluster (builtins must throw the spec error on an incompatible this).

The primitive-wrapper prototype methods do not perform the spec this brand
check when invoked reflectively on an incompatible receiver. Instead the call
falls back to Object.prototype and returns "[object Object]" rather than
throwing a TypeError.

Affected (each should throw TypeError on a non-matching receiver):

Number.prototype.valueOf, Number.prototype.toLocaleString
Boolean.prototype.toString, Boolean.prototype.valueOf
Symbol.prototype.toString, Symbol.prototype.valueOf
BigInt.prototype.toString, BigInt.prototype.valueOf

(Number.prototype.toFixed/toString/toExponential/toPrecision already throw via
the computed-key dispatch.)

Repro

Number.prototype.valueOf.call({});      // Perry: "[object Object]"  Node: TypeError
Boolean.prototype.toString.call({});    // Perry: "[object Object]"  Node: TypeError
Symbol.prototype.toString.call({});     // Perry: "[object Object]"  Node: TypeError
BigInt.prototype.valueOf.call({});      // Perry: "[object Object]"  Node: TypeError

Related wrong-value bug

Even on a valid receiver, the reflective toString returns the wrong value
(the generic Object.prototype.toString is used):

Symbol.prototype.toString.call(Symbol("x")); // Perry: "[object Symbol]"  Node: "Symbol(x)"
BigInt.prototype.toString.call(5n, 2);       // Perry: "[object BigInt]"  Node: "101"

Suggested fix

Install dedicated brand-checking thunks on Number/Boolean/Symbol/BigInt
.prototype (mirror object/collection_proto_thunks.rs): read IMPLICIT_THIS,
verify it is the matching primitive (or its boxed wrapper), throw TypeError
otherwise, and re-dispatch to the existing per-type logic via
js_native_call_method — which also fixes the wrong-value reflective toString.

I am taking this with #4099 and #4102 in one runtime reflective-builtins PR cut. Planned scope: fix reflective collection set receiver validation, primitive wrapper prototype brand/value dispatch, and dynamic instanceof / constructor @@hasInstance recognition for Array/Object/Date without taking the separate function-source or typed-array-view work.

Investigation note (saves the next implementer a dead-end):

The obvious fix — install brand-checking thunks on Number.prototype /
Boolean.prototype in global_this::populate_builtin_prototype_methods (the
exact recipe that works for the collection prototypes in
collection_proto_thunks.rs) — does not work here.

Confirmed empirically:

populate_builtin_prototype_methods("Number"/"Boolean", proto) is called
(lazily, when the globalThis builtin singleton is first built), and the
thunks install onto that singleton prototype object.
But reflective Number.prototype.valueOf.call({}) still returns
"[object Object]" and never reaches the installed thunk — even after the
singleton has been populated.

So Number.prototype.valueOf does not read its valueOf from the
singleton-populated prototype the way Map.prototype.set does. It resolves the
method via a different path (it ends up at the shared
global_this_builtin_noop_thunk, whose reflective .call re-dispatches by
name onto the receiver — js_native_call_method({}, "valueOf") → falls
through to Object.prototype.valueOf → [object Object]).

The real fix needs interception at the actual reflective-dispatch site, e.g.
try_dispatch_value_called_proto_method / the value-called-proto handling in
native_call_method.rs, with enough context to know the method came off
Number/Boolean/Symbol/BigInt.prototype (the noop currently loses that
origin), or making Number.prototype resolve to the populated singleton
prototype. This is a deeper change than the collection recipe, hence deferred.

Scope reminder for this issue: Number.prototype.{valueOf,toLocaleString,
toFixed,toString,toExponential,toPrecision}, Boolean.prototype.{toString,
valueOf}, Symbol.prototype.{toString,valueOf}, BigInt.prototype.{toString,
valueOf} on an incompatible receiver must throw TypeError; the same fix also
corrects reflective Symbol/BigInt toString returning [object Symbol] /
[object BigInt] (should be Symbol(x) / the radix string).

fix(runtime): brand-check primitive-wrapper prototype methods (#4100)

fix(runtime): brand-check primitive-wrapper prototype methods (#4100) (…

Draft PR opened for this: #4115

Reopening — #4112 fixed most of this (computed-key access + Symbol/BigInt + the wrong-value reflective toString), but a residual remains for the direct / extracted member-access form of Number.prototype.* and Boolean.prototype.*. Verified on main (d990b021e):

// computed access — correctly throws (fixed by #4112)
(Number.prototype as any)["valueOf"].call({})   // TypeError ✓

// direct member access — still NOT brand-checked
Number.prototype.valueOf.call({})               // Perry: "[object Object]"   Node: TypeError
Number.prototype.toString.call({})              // Perry: "[object Object]"   Node: TypeError
Boolean.prototype.valueOf.call({})              // Perry: "[object Object]"   Node: TypeError

// extraction has the same gap
const v = Number.prototype.valueOf; v.call({})  // Perry: "[object Object]"   Node: TypeError

Symbol/BigInt direct access does throw (no codegen fast-path), so this is specific to Number/Boolean. The direct Number.prototype.<m> read is lowered by codegen to a path that resolves the method without going through the installed brand-check thunk (it ends up at the Object.prototype fallback), whereas the computed ["<m>"] read does a generic property get that hits the thunk. The fix is to make the direct-member Number.prototype.<m> / Boolean.prototype.<m> value read resolve to the same installed thunk (or route the reflective dispatch through the brand check regardless of access form).

(Same direct-vs-computed split was visible in the original triage; #4112's primitive_proto_thunks only intercepts the computed/generic path.)

Correction to the root cause above — the HIR for the direct and computed property reads is identical, so it's not a property-read divergence. The real trigger is the statically-typed .call lowering:

Number.prototype.valueOf.call({})              // Perry: "[object Object]"  Node: TypeError
(Number.prototype as any).valueOf.call({})     // throws ✓  (as-any on receiver)
(Number.prototype.valueOf as any).call({})     // throws ✓  (as-any on method)
Number.prototype.valueOf.call({} as any)       // "[object Object]"  (as-any on arg — no effect)

When Number.prototype.valueOf is statically typed (TS knows it as () => number), codegen lowers the .call(...) through a typed/optimized dispatch path that resolves the method without going through the installed primitive_proto_thunks brand-check. Erasing the type with as any on the receiver or the method drops it to the dynamic js_native_call_method path, which hits the thunk and throws correctly.

So #4112's thunks are correct; the remaining gap is that the typed-.call codegen fast-path for Number/Boolean prototype methods bypasses them. This is a very niche reflective pattern (TS would normally reject the receiver-type mismatch anyway), so low priority — but tracking it for completeness.

fix(hir): brand-check typed Number/Boolean prototype .call (#4100) (#…

fix(runtime): avoid primitive-method recursion via String.prototype r…

[codex] Align primitive wrapper receivers (#4161)

fix(runtime,hir): observable spec-order argument coercion for reflect…

Navigation Menu

Repository navigation

runtime: Number/Boolean/Symbol/BigInt prototype methods don't brand-check this (reflective call returns [object Object] instead of TypeError) (#3662) #4100

Repro

Related wrong-value bug

Suggested fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

runtime: Number/Boolean/Symbol/BigInt prototype methods don't brand-check this (reflective call returns [object Object] instead of TypeError) (#3662) #4100

Description

Repro

Related wrong-value bug

Suggested fix

Activity

andrewtdiz commented on Jun 2, 2026

proggeramlug commented on Jun 2, 2026

andrewtdiz commented on Jun 2, 2026

proggeramlug commented on Jun 2, 2026

proggeramlug commented on Jun 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions