[Webkit-unassigned] [Bug 263647] Function.caller returns null when callee is inlined into apply function

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=263647

David Degazio <d_degazio at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d_degazio at apple.com
             Status|NEW                         |ASSIGNED

--- Comment #2 from David Degazio <d_degazio at apple.com> ---
Investigated this a bit, it seems to have a pretty straightforward cause. Per the spec (https://tc39.es/ecma262/#sec-reflect.apply), Reflect.apply does:

1. If IsCallable(target) is false, throw a TypeError exception.
2. Let args be ? CreateListFromArrayLike(argumentsList).
3. Perform PrepareForTailCall().
4. Return ? Call(target, thisArgument, args).

In the interpreter, we handle 3. and 4. by emitting a tail_call_varargs, and so long as f0 is not inlined, we observe the correct behavior on all tiers (printing the source of f9). However, if f0 is inlined when Reflect.apply is compiled in DFG, it's no longer a tail call - we don't set up a new frame or anything, so it executes in the frame of Reflect.apply. This essentially skips step 3. Since we didn't destroy the frame of Reflect.apply when it called f0, f0.caller is Reflect.apply, and since that's a strict built-in function f0.caller returns null. We should instead be acting like the frame of Reflect.apply was destroyed, and see the caller of Reflect.apply - f9.

In order to fix this, I think we need to be careful when inlining tail calls in DFG and FTL. If we didn't inline these calls, then the call stack would really correlate with the spec execution context, and the correct caller would be returned. To remedy this issue, maybe we can add a node before inlined tail calls that updates the frame callee with the inlined function. I don't think this is super complex, although it's not trivial since I think we'll want a new node type. The bigger issue is I imagine there might be some performance hit by adding these stores before every inlined tail call - once I have a prototype fix I'll have to see how bad the fallout is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231101/6274b3fb/attachment.htm>