You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current Realm record in 9.2.2 [[Construct]], step 5 is the Realm of the caller execution context. This has been the way since ES1, which implemented in [[Construct]] in terms of [[Call]]. When ES6 added the notion of different Realms, this part of the spec wasn't updated to handle the case when the caller and callee Realms are different, but I can't tell if no update happened on purpose or if this was just an oversight. (Construct semantics changed multiple times during ES6, so it's hard for me to tell for sure).
This is for example visible when OrdinaryCreateFromConstructor throws an error, because the error has to be created in the caller Realm. Contrary to that, built-in functions always use the callee Realm:
varotherGlobal;if(typeofnewGlobal==="function"){otherGlobal=newGlobal();}elseif(typeofcreateGlobalObject==="function"){otherGlobal=createGlobalObject();}elseif(typeofRealm!=="undefined"){otherGlobal=Realm.global(Realm.createAllowCrossRealmAccess());}elseif(typeofWScript!=="undefined"){otherGlobal=WScript.LoadScript("this","samethread");}else{thrownewError("can't create global");}// Should print "caller" per current spec.varf=otherGlobal.eval(`(function(){})`);var{proxy, revoke}=Proxy.revocable(function(){},{});revoke();try{Reflect.construct(f,[],proxy);}catch(e){print(einstanceofTypeError ? "caller" : "callee");}// Should print "callee" per current spec.try{Reflect.construct(otherGlobal.Array,[],proxy);}catch(e){print(einstanceofTypeError ? "caller" : "callee");}
And this also means the object created in 9.2.2 [[Construct]] has to be created in the caller Realm. This is right now not observable, but IIRC some new proposals like to assign a Realm to each object (and not only function objects), so it could be an issue in the future.
Currently only V8 passes the first test case (SM/JSC print "callee" twice, Chakra prints "caller" twice). And neither SpiderMonkey nor V8 pass the second test case. (I couldn't test it on JSC/Chakra, because I didn't find any shell builtins to retrieve the Realm/Global of an object).
So the question is, does it make sense to move OrdinaryCreateFromConstructor after PrepareForOrdinaryCall or do we want to keep things as is?
The text was updated successfully, but these errors were encountered:
The current Realm record in 9.2.2 [[Construct]], step 5 is the Realm of the caller execution context. This has been the way since ES1, which implemented in [[Construct]] in terms of [[Call]]. When ES6 added the notion of different Realms, this part of the spec wasn't updated to handle the case when the caller and callee Realms are different, but I can't tell if no update happened on purpose or if this was just an oversight. (Construct semantics changed multiple times during ES6, so it's hard for me to tell for sure).
This is for example visible when
OrdinaryCreateFromConstructor
throws an error, because the error has to be created in the caller Realm. Contrary to that, built-in functions always use the callee Realm:And this also means the object created in 9.2.2 [[Construct]] has to be created in the caller Realm. This is right now not observable, but IIRC some new proposals like to assign a Realm to each object (and not only function objects), so it could be an issue in the future.
Currently only V8 passes the first test case (SM/JSC print "callee" twice, Chakra prints "caller" twice). And neither SpiderMonkey nor V8 pass the second test case. (I couldn't test it on JSC/Chakra, because I didn't find any shell builtins to retrieve the Realm/Global of an object).
So the question is, does it make sense to move
OrdinaryCreateFromConstructor
afterPrepareForOrdinaryCall
or do we want to keep things as is?The text was updated successfully, but these errors were encountered: