Editorial: Create the realm execution context slightly later #3497
Conversation
That is, in InitializeHostDefinedRealm, take the steps that create + push the realm execution context, and move them to after the realm's fields have been finalized.
| 1. Perform ? SetDefaultGlobalBindings(_realm_). | ||
| 1. Create any host-defined global object properties on _global_. |
There was a problem hiding this comment.
Is the only reason we can't also move these lines up because SetDefaultGlobalBindings might throw? If so, should we (normatively) reconsider whether those property definitions should be permitted to throw?
There was a problem hiding this comment.
Is the only reason we can't also move these lines up because
SetDefaultGlobalBindingsmight throw?
Well, the only other possible reason would be that those remaining steps need the realm EC to exist (and maybe that it be on the EC stack). That isn't the case if the global object is ordinary, but if it's a host-defined exotic object, then I suppose its relevant internal methods could be specified to access the realm EC.
|
Ah, in the sense of "the current Realm Record" = "the Realm component of the running execution context". But if we first changed IHDR as described in #3274 (comment), that would give you a more direct way to access the realm being created, and then this PR wouldn't be a problem? |
|
Yes, that would be fine. I just need a reasonable way to get the (new) realm. |
InitializeHostDefinedRealm(IHDR), in addition to creating a realm, also creates an execution context (EC) to house it, and pushes that EC onto the EC stack. In the status quo, the EC-related steps appear in the midst of the realm-creation steps, which is odd, and doesn't appear to be necessary. (You might think that the later realm-creation steps somehow assume that the realm EC exists and has been pushed on the EC stack, but as far as I can tell, they don't. I think it's just an artifact of how IHDR was introduced in ES6.)This PR moves the EC-related steps to a point after the realm's fields have been finalized.
(This makes it easier to see that the early settings of
[[GlobalObject]]and[[GlobalEnv]]to*undefined*are superfluous. I would have deleted those steps, but that overlaps with PR #3445.)I would have preferred to move the EC-related steps to just before the Return step. However, that would be a change in behavior. The invocation of
SetDefaultGlobalBindingscan return an abrupt completion, which is immediately returned by IHDR. In such a case, the status quo says that the EC-related things have happened, which is a side-effect that can be observed by IHDR's caller. In particular, when the HTML spec invokes IHDR, it ignores the return value; it fetches the realm EC from the EC stack regardless of whether IHDR returned an abrupt completion.(Mind you, I think the only way that
SetDefaultGlobalBindingscould throw is if IHDR's caller provided a global object that was specifically designed to make that happen.)I suggested this change in #3445 (comment)
This should probably have been a quick follow-up to PR #3139.
See also PR #3274, which considers changing some of the linkage between IHDR and its caller.