diff --git a/spec.html b/spec.html index 31b05e8afe..20eeca471d 100644 --- a/spec.html +++ b/spec.html @@ -4427,7 +4427,7 @@
An execution context is a specification device that is used to track the runtime evaluation of code by an ECMAScript implementation. At any point in time, there is at most one execution context per agent that is actually executing code. This is known as the agent's running execution context. All references to the running execution context in this specification denote the running execution context of the surrounding agent.
The execution context stack is used to track execution contexts. The running execution context is always the top element of this stack. A new execution context is created whenever control is transferred from the executable code associated with the currently running execution context to executable code that is not associated with that execution context. The newly created execution context is pushed onto the stack and becomes the running execution context.
-An execution context contains whatever implementation specific state is necessary to track the execution progress of its associated code. Each execution context has at least the state components listed in
Each execution context is represented as an ExecutionContext Record, with at least the fields listed in
- Component + Field Name | - Purpose + Value Type + | ++ Meaning |
---|---|---|
- code evaluation state + [[CodeEvaluationState]] + | ++ implementation-specific |
Any state needed to perform, suspend, and resume evaluation of the code associated with this execution context.
@@ -11868,15 +11874,21 @@ Execution Contexts |
- Function + [[Function]] | - If this execution context is evaluating the code of a function object, then the value of this component is that function object. If the context is evaluating the code of a |Script| or |Module|, the value is *null*. + a function object or *null* + | ++ If this execution context is evaluating the code of a function object, then the value of this field is that function object. If the context is evaluating the code of a |Script| or |Module|, the value is *null*. |
- Realm + [[Realm]] + | ++ a Realm Record |
The Realm Record from which associated code accesses ECMAScript resources.
@@ -11884,32 +11896,41 @@ Execution Contexts |
- ScriptOrModule + [[ScriptOrModule]] + | ++ a Module Record, a Script Record, or *null* | - The Module Record or Script Record from which associated code originates. If there is no originating script or module, as is the case for the original execution context created in InitializeHostDefinedRealm, the value is *null*. + The Module Record or Script Record from which associated code originates. If there is no originating script or module, as is the case for the original ExecutionContext Record created in InitializeHostDefinedRealm, the value is *null*. |
Evaluation of code by the running execution context may be suspended at various points defined within this specification. Once the running execution context has been suspended a different execution context may become the running execution context and commence evaluating its code. At some later time a suspended execution context may again become the running execution context and continue evaluating its code at the point where it had previously been suspended. Transition of the running execution context status among execution contexts usually occurs in stack-like last-in/first-out manner. However, some ECMAScript features require non-LIFO transitions of the running execution context.
-The value of the Realm component of the running execution context is also called the current Realm Record. The value of the Function component of the running execution context is also called the active function object.
-ECMAScript code execution contexts have the additional state components listed in
The value of the running execution context's [[Realm]] field is also called the current Realm Record. The value of the running execution context's [[Function]] field is also called the active function object.
+ECMAScript code ExecutionContext Records have the additional fields listed in
- Component + Field Name | - Purpose + Value Type + | ++ Meaning |
---|---|---|
- LexicalEnvironment + [[LexicalEnvironment]] + | ++ an Environment Record |
Identifies the Environment Record used to resolve identifier references made by code within this execution context.
@@ -11917,7 +11938,10 @@ Execution Contexts |
- VariableEnvironment + [[VariableEnvironment]] + | ++ an Environment Record |
Identifies the Environment Record that holds bindings created by |VariableStatement|s within this execution context.
@@ -11925,7 +11949,10 @@ Execution Contexts |
- PrivateEnvironment + [[PrivateEnvironment]] + | ++ a PrivateEnvironment Record or *null* |
Identifies the PrivateEnvironment Record that holds Private Names created by |ClassElement|s in the nearest containing class. *null* if there is no containing class.
@@ -11933,23 +11960,28 @@ Execution Contexts |
The LexicalEnvironment and VariableEnvironment components of an execution context are always Environment Records.
-Execution contexts representing the evaluation of Generators have the additional state components listed in
ExecutionContext Records representing the evaluation of Generators have the additional fields listed in
- Component + Field Name | - Purpose + Value Type + | ++ Meaning |
---|---|---|
- Generator + [[Generator]] + | ++ an Object |
The Generator that this execution context is evaluating.
@@ -11957,7 +11989,7 @@ Execution Contexts |
In most situations only the running execution context (the top of the execution context stack) is directly manipulated by algorithms within this specification. Hence when the terms “LexicalEnvironment”, and “VariableEnvironment” are used without qualification they are in reference to those components of the running execution context.
+In most situations only the running execution context (the top of the execution context stack) is directly manipulated by algorithms within this specification.
An execution context is purely a specification mechanism and need not correspond to any particular artefact of an ECMAScript implementation. It is impossible for ECMAScript code to directly access or observe an execution context.
At any particular time, _scriptOrModule_ (a Script Record, a Module Record, or *null*) is the active script or module if all of the following conditions are true:
At any particular time, an execution is prepared to evaluate ECMAScript code if all of the following conditions are true:
Host environments may prepare an execution to evaluate code by pushing execution contexts onto the execution context stack. The specific steps are implementation-defined.
-The specific choice of Realm is up to the host environment. This initial execution context and Realm is only in use before any callback function is invoked. When a callback function related to a Job, like a Promise handler, is invoked, the invocation pushes its own execution context and Realm.
+Host environments may prepare an execution to evaluate code by pushing ExecutionContext Records onto the execution context stack. The specific steps are implementation-defined.
+The specific choice of Realm is up to the host environment. This initial ExecutionContext Record and Realm is only in use before any callback function is invoked. When a callback function related to a Job, like a Promise handler, is invoked, the invocation pushes its own ExecutionContext Record and Realm.
Particular kinds of Jobs have additional conformance requirements.
@@ -13415,21 +13447,21 @@No matter how control leaves the |Block| the LexicalEnvironment is always restored to its former state.
+No matter how control leaves the |Block| the [[LexicalEnvironment]] is always restored to its former state.
`let` and `const` declarations define variables that are scoped to the running execution context's LexicalEnvironment. The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's |LexicalBinding| is evaluated. A variable defined by a |LexicalBinding| with an |Initializer| is assigned the value of its |Initializer|'s |AssignmentExpression| when the |LexicalBinding| is evaluated, not when the variable is created. If a |LexicalBinding| in a `let` declaration does not have an |Initializer| the variable is assigned the value *undefined* when the |LexicalBinding| is evaluated.
+`let` and `const` declarations define variables that are scoped to the running execution context's [[LexicalEnvironment]]. The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's |LexicalBinding| is evaluated. A variable defined by a |LexicalBinding| with an |Initializer| is assigned the value of its |Initializer|'s |AssignmentExpression| when the |LexicalBinding| is evaluated, not when the variable is created. If a |LexicalBinding| in a `let` declaration does not have an |Initializer| the variable is assigned the value *undefined* when the |LexicalBinding| is evaluated.
A `var` statement declares variables that are scoped to the running execution context's VariableEnvironment. Var variables are created when their containing Environment Record is instantiated and are initialized to *undefined* when created. Within the scope of any VariableEnvironment a common |BindingIdentifier| may appear in more than one |VariableDeclaration| but those declarations collectively define only one variable. A variable defined by a |VariableDeclaration| with an |Initializer| is assigned the value of its |Initializer|'s |AssignmentExpression| when the |VariableDeclaration| is executed, not when the variable is created.
+A `var` statement declares variables that are scoped to the running execution context's [[VariableEnvironment]]. Var variables are created when their containing Environment Record is instantiated and are initialized to *undefined* when created. Within the scope of any [[VariableEnvironment]] a common |BindingIdentifier| may appear in more than one |VariableDeclaration| but those declarations collectively define only one variable. A variable defined by a |VariableDeclaration| with an |Initializer| is assigned the value of its |Initializer|'s |AssignmentExpression| when the |VariableDeclaration| is executed, not when the variable is created.
If a |VariableDeclaration| is nested within a with statement and the |BindingIdentifier| in the |VariableDeclaration| is the same as a property name of the binding object of the with statement's Object Environment Record, then step
If a |VariableDeclaration| is nested within a with statement and the |BindingIdentifier| in the |VariableDeclaration| is the same as a property name of the binding object of the with statement's Object Environment Record, then step
No matter how control leaves the embedded |Statement|, whether normally or by some form of abrupt completion or exception, the LexicalEnvironment is always restored to its former state.
+No matter how control leaves the embedded |Statement|, whether normally or by some form of abrupt completion or exception, the [[LexicalEnvironment]] is always restored to its former state.
No matter how control leaves the |SwitchStatement| the LexicalEnvironment is always restored to its former state.
+No matter how control leaves the |SwitchStatement| the [[LexicalEnvironment]] is always restored to its former state.
No matter how control leaves the |Block| the LexicalEnvironment is always restored to its former state.
+No matter how control leaves the |Block| the [[LexicalEnvironment]] is always restored to its former state.
<button type="button" onclick="import('./foo.mjs')">Click me</button>
- there will be no active script or module at the time the
there will be no active script or module at the time the
An implementation of HostLoadImportedModule must conform to the following requirements:
@@ -29000,7 +29032,7 @@The eval code cannot instantiate variable or function bindings in the variable environment of the calling context that invoked the eval if either the code of the calling context or the eval code is strict mode code. Instead such bindings are instantiated in a new VariableEnvironment that is only accessible to the eval code. Bindings introduced by `let`, `const`, or `class` declarations are always instantiated in a new LexicalEnvironment.
+The eval code cannot instantiate variable or function bindings in the variable environment of the calling context that invoked the eval if either the code of the calling context or the eval code is strict mode code. Instead such bindings are instantiated in a new [[VariableEnvironment]] that is only accessible to the eval code. Bindings introduced by `let`, `const`, or `class` declarations are always instantiated in a new [[LexicalEnvironment]].