Should the dup/getxprop case in EmitAssignment happen for gname as well?

NEW
Unassigned

Status

()

4 years ago
3 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

After bug 1145491 we will sometimes use gname ops even though our scope is not a global; in that case we detect it at runtime and do what we'd do for the name ops instead.  Testcase based on js/src/jit-test/tests/basic/bug1106982.js :

var x = "wrong";
var t = {x: "x"};
var hits = 0;
var p = new Proxy(t, {
    has(t, id) {
        var found = id in t;
        if (++hits == 2)
            delete t[id];
        return found;
    },
    get(t, id) { return t[id]; }
});
evaluate(`function testFunc() {
    x += " x";
}`, { compileAndGo: false });

var cloneFunc = clone(testFunc, p);
cloneFunc();
assertEq(hits, 2);
assertEq(t.x, "undefined x");

Now this passes right now, because we end up doing a has() from bind(g)name and another has() from get(g)name, just like in the original testcase we do has() from bindname and has() from getxprop.

But presumably we'll fix this at some point so the getxprop doesn't do a has() here.

Should we be doing the getxprop thing in the gname case as well, in EmitAssignment?
(Reporter)

Comment 1

4 years ago
The other option is that maybe this doesn't matter.  You can only tell the difference when using non-syntactic scope chains that involve proxies, and for the most part no one does that (debugger scope stuff is the one exception, but that's not a proxy looking for holes in our impl).
(Reporter)

Updated

3 years ago
Depends on: 1179711
You need to log in before you can comment on or make changes to this bug.