Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unclear semantics for ScriptEvaluation when scriptRecord.[[Realm]] is undefined #3326

Closed
shicks opened this issue May 11, 2024 · 1 comment · Fixed by #3332
Closed

Unclear semantics for ScriptEvaluation when scriptRecord.[[Realm]] is undefined #3326

shicks opened this issue May 11, 2024 · 1 comment · Fixed by #3332
Labels
layering affects the public spec interface and may require updates to integrating specs

Comments

@shicks
Copy link

shicks commented May 11, 2024

In section 16.1.5 the abstract operation ParseScript is defined as accepting a realm parameter, which may be either a Realm Record or undefined, and is assigned directly into the [[Realm]] field of the resulting record. 16.1.4 reinforces that [[Realm]] may be undefined if "if not yet assigned" (this is in contrast with the following section on Module Records, where [[Realm]] is never undefined). Later, 16.1.6 defines the first step of ScriptEvaluation as

  1. Let globalEnv be scriptRecord.[[Realm]].[[GlobalEnv]].

This implicitly assumes scriptRecord.[[Realm]] is defined, but I don't see anything in the spec to establish this guarantee - not even an Assert. If it's required to have a defined realm, then ParseScript should be updated to no longer accept undefined. On the other hand, if it's allowed to be undefined, then the undefined case should be handled in ScriptEvaluation (presumably either via CreateRealm, or else returning a throw completion).

@bakkot
Copy link
Contributor

bakkot commented May 15, 2024

Pretty sure this cannot in fact be undefined. 698819c introduced that field, and prior to that commit the [[Realm]] of a Module Record could briefly be undefined if not yet assigned, so our best guess is that this was a refactoring issue during the authoring of that commit.

We'll update the type of that argument and field.

@michaelficarra michaelficarra added the layering affects the public spec interface and may require updates to integrating specs label May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
layering affects the public spec interface and may require updates to integrating specs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants