Array methods absent from %TypedArray%.prototype answer instead of throwing (flat, flatMap, push, pop, shift, unshift, splice, toSpliced) #8138

Activity

1. proggeramlug commented on Aug 15, 2026

   

   proggeramlug

   on Aug 15, 2026

   ContributorAuthor

   More actions

   The "Suggested shape" premise is false — measured

   This issue proposes:

   dispatch_typed_array_method … and dispatch_buffer_method … already return
   None / "is not a function" for unrecognised names, so the missing piece is
   preventing the static HIR folds from claiming these nine

   The first half is only true for dispatch_buffer_method. Measured on main
   @ a3118cfea, oracle node 26.5.1, --profile perry-dev,
   PERRY_NO_AUTO_OPTIMIZE=1:

   function opaque(x: any): any { return x; }
   const i32 = new Int32Array([1, 2, 3]);
   const arr = [1, 2, 3];
   const o: any = {};
   opaque(i32).nosuch()   // perry ""   node TypeError: opaque(...).nosuch is not a function
   opaque(arr).nosuch()   // perry ""   node TypeError: opaque(...).nosuch is not a function
   o.nosuch()             // perry TypeError: nosuch is not a function      (right shape)
   opaque(u8).nosuch()    // perry TypeError: (Buffer).nosuch is not a function

   dispatch_typed_array_method does return None for an unrecognised name, but
   the dispatch tower's tail then answers the empty string — and it does so
   for a plain array receiver too, not just a typed array. So "decline the
   fold" produces "", not a TypeError: the nine names would move from a wrong
   value to a different wrong value.

   Making them throw therefore means introducing an unknown-method throw for
   array-ish receivers in general — a much broader behavioural change than the
   nine names, with its own blast radius (every is_array_expr-classified
   receiver reaching the tower's tail). And the static-receiver half
   (i32.flat(), 11 of the 29 measured rows) has to decline in is_array_expr /
   the HIR folds, which puts perry-codegen in the diff and brings the
   perry-codegen integration suite (1476 passed / 9 failed baseline, not run
   per-PR) into scope.

   Full measured table on a3118cfea

   u8.* rows already throw with the right shape but the wrong reason
   (dispatch_buffer_method's name list has no entry). i32.* rows do not throw
   at all:

   expression	perry	node
   opaque(i32).flat()	[]	TypeError
   opaque(i32).flatMap(f)	[5.08e-321,4.24e-314,1.5e-323] — garbage	TypeError
   opaque(i32).push(9)	0	TypeError
   opaque(i32).pop()	undefined	TypeError
   opaque(i32).shift()	undefined	TypeError
   opaque(i32).unshift(9)	0	TypeError
   opaque(i32).splice(1,1)	[]	TypeError
   opaque(i32).toSpliced(1,1)	[]	TypeError
   opaque(i32).concat([9])	[9]	TypeError
   opaque(u8).flat()	[]	TypeError
   opaque(u8).toSpliced(1,1)	[]	TypeError
   i32.flat() (static)	[]	TypeError
   (i32 as any).push(9) (static)	1, and the binding is corrupted	TypeError
   (i32 as any).pop() (static)	9	TypeError
   (i32 as any).toSpliced(1,1) (static)	[9]	TypeError
   (u8 as any).flat() (static)	[]	TypeError
   (u8 as any).toSpliced(1,1) (static)	[]	TypeError

   The static rows are worse than the issue records. After
   (i32 as any).push(9); (i32 as any).pop() the receiver itself is destroyed:
   Array.from(i32) reads [9] where node has [1,2,3] — the ArrayHeader
   mutators rewrote the TypedArrayHeader's {length, capacity} prefix. Any fix
   needs a control asserting the receiver's contents are UNCHANGED after each
   attempted call, not only that the call threw.

   Suggested re-scoping

   1. Decide the general question first: should an unknown method on an array /
      typed-array receiver throw? That is the actual defect and it subsumes all
      nine names. opaque(arr).nosuch() returning "" is its own bug.
   2. Only then gate the nine names, and only if the general throw does not
      already cover them.
   3. The message shape reachable today is TypeError: <name> is not a function
      (the object path) or TypeError: (Buffer).<name> is not a function (the
      buffer path); node's opaque(...).<name> is not a function needs the
      call-site expression text, which the runtime does not have. A test should
      assert the shape, not byte-equality with node.

   Measured while fixing #8149 / #8139 (PR #8186), which were filed from the same
   sweep. Those two do not share a cause with this one: #8149 is the
   receiver-routing family, #8139 is a missing arm in a value-kind dispatcher, and
   this issue is about method existence.
2. proggeramlug

   closed this as completedin #8280on Aug 17, 2026