Unexpected result for f.caller when the actual caller of f is a built-in function such as Array.prototype.forEach
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
People
(Reporter: claude.pache, Unassigned)
References
(Blocks 1 open bug)
Details
function f() {
let r;
[0].forEach(function g() {
r = g.caller;
})
return r;
}
f();
Expected result: null (in lieu of Array.prototype.forEach, which is censored)
Actual result: f
Updated•6 years ago
|
| Comment hidden (offtopic) |
Comment 2•6 years ago
|
||
Please ignore the previous comment, it was intended for bug 1618357.
Comment 3•6 years ago
|
||
CallerGetterImpl uses NonBuiltinScriptFrameIter, so we're explicitly skipping over any built-in frames, which includes self-hosted frames like ArrayForEach. We're likely need another frame iterator for .caller, because the proposed spec text doesn't ignore built-in frames, so when the caller is any built-in (native or self-hosted), we need to return null. But then there's Function.prototype.call and Function.prototype.apply, which per the spec use tail call semantics, and we're likely forced to ignore these two functions for .caller for backward compatibility reasons.
Updated•6 years ago
|
Updated•6 years ago
|
| Reporter | ||
Comment 4•6 years ago
|
||
(Modifying the bug summary, in order to remove my misguessing of the cause, see comment #3)
| Reporter | ||
Comment 5•6 years ago
|
||
I note that built-in frames are also skipped in stacks provided by (new Error).stack, whereas v8 and jsc don’t skip them.
Comment 6•6 years ago
|
||
Displaying all built-in frames may reveal internal function names, at least for self-hosted functions. This is already visible today in JSC:
>>> function compare(a, b) { print(new Error().stack); return a - b; }
undefined
>>> [1, 2].sort(compare);
compare@/tmp/interpreter:1:41
merge@[native code]
mergeSort@[native code]
comparatorSort@[native code]
sort@[native code]
global code@/tmp/interpreter:1:12
1,2
Updated•3 years ago
|
Description
•