Layering: track execution contexts' script/module#242
Layering: track execution contexts' script/module#242domenic wants to merge 1 commit intotc39:masterfrom domenic:track-script-module
Conversation
There was a problem hiding this comment.
The sentence "If more than one parse or early error is present, the number and ordering of reported errors is implementation dependent but at least one error must be reported." allows to report multiple errors at once, but the next step "Throw a SyntaxError exception." limits this to a single error.
Also "Throw a SyntaxError exception." is not correct for early ReferenceErrors. (Me shakes fist at early reference errors.) The current 15.2.1.16.1 ParseModule abstract operation needs to be fixed, too.
There was a problem hiding this comment.
Interesting. Note that I am essentially copying ParseModule here, so ParseModule will also have both these problems.
I don't believe your first paragraph is correct though. You can report multiple errors independently of throwing a SyntaxError. That step is just requiring that at least one SyntaxError be thrown.
Do you have suggested replacement text for both here and ParseModule? Maybe it would suffice to just replace "Throw a SyntaxError exception" with "Throw a SyntaxError or ReferenceError exception, according to the error indicated"?
There was a problem hiding this comment.
If there are early syntax and reference errors, a single error kind is no longer sufficient.
|
Functions created in 19.2.1.1.1 CreateDynamicFunction or indirect evals won't be associated with a "Script or Module". Does this pose a problem? And ECMAScript needs a better term for "Script or Module", because repeating "Script or Module" every time a script or module is referenced is kind of awkward. (That's not a criticism on this PR, but rather a general issue.) |
Yes, I think it could; I will fix that. Thanks for finding it.
I agree. I couldn't come up with anything on the spot. (I thought "code unit", but Unicode already took that one...) |
FWIW I'm currently using "Program" (based on ES5's Program parser production). But "ProgramUnit" or "ApplicationUnit" are probably better names, especially because "program" is already used in the spec to describe the running ECMAScript program itself. |
|
New version uploaded, should be better now! Thanks @anba. |
I took another look at this and I can't see what you're talking about actually. CreateDynamicFunction calls FunctionInitialize, which should have no problem setting up the association. |
|
In FunctionInitialize:
The active function object during CreateDynamicFunction is the intrinsic %Function%, and %Function%.[[ScriptOrModule]] is The same issue is present for indirect eval calls:
ctx's ScriptOrModule component is |
|
Actually, all built-in functions must have a [[ScriptOrModule]] value. We just don't say what it is. But, this is probably sub-optimal. I will try to work out something so that built-in functions have undefined [[ScriptOrModule]], and are skipped over when calculating an execution context's ScriptOrModule. |
As I said above, [[ScriptOrModule]] is initialized with |
|
Yes, and as I said above, [[ScriptOrModule]] is not initialized with undefined per that clause; it is initialized with whatever the host environment says:
|
|
6.1.7.2 applies to all objects, it's not limited to a specific kind of object. So if the specification adds [[ScriptOrModule]] to built-in function objects, but does not assign a specific value to [[ScriptOrModule]], the default value for [[ScriptOrModule]] is |
|
I see. In any case, fixed; built-in functions are now explicitly skipped in this calculation. Let me know if I got it right? @bterlson we should decide on whether to adopt "program" as a name for "script or module" before merging, especially now that I've introduced an abstract op (and thus a link ID) with that name. |
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XMl-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
|
I find program to be more confusing (I consider a program to be composed of multiple libraries and such) so have a slight preference for scriptOrModule but am fine either way really. |
|
(Suggestion on the naming based on |
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
|
The ScriptEvaluation change for empty scripts also fixes https://bugs.ecmascript.org/show_bug.cgi?id=4345 . |
There was a problem hiding this comment.
Perhaps "The" instead of "An" to suggest that there is only one of these (and soon to be one-per-continent once that language lands)?
There was a problem hiding this comment.
This was really just splitting up into two paragraphs what was previously one long paragraph but happy to make that change while I'm here.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
|
Seems good to go! @domenic you ready? :-P |
|
Yes, do it! :D |
|
Looks like there is a full copy of the spec in the PR, which most likely originated from a merge conflict. I guess @bterlson can take care of it while rebasing. |
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
|
Yes I have discovered this and am fixing presently. |
|
Arghleblargle, will fix, one sec. |
Fixes #78. Introduces the concept of a Script Record as a counterpart to a Module Record, and adds [[HostDefined]] fields to both of them. Every execution environment now has ScriptOrModule component pointing back to its "creator" script or module: - Top level script/module execution contexts point to the appropriate script/module. - Function execution contexts for functions declared at top level point to that of the containing script/module. - Function execution contexts for functions declared inside other functions point to that of the containing function, skipping built-in functions. - Eval execution contexts point to that of their containing function (skipping built-in functions, including `eval` itself). - Job execution contexts (which are largely a spec artifact) point to the script/module that originally enqueued the job. In the course of doing this, a couple other substantial changes were introduced: - Factored out ParseScript and ScriptEvaluation abstract operations, so that script parsing now better parallels module parsing. - Added HostReportErrors for reporting both parsing errors and runtime errors, and wired it in to parsing and NextJob as appropriate.
|
ok will wait for @domenic :-P |
|
done |
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
|
Committed as 698819c (added a note to the commit message about the bugzilla bug fixed :-P) |
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include: - Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones). - Let ES track the execution context stack, and the corresponding stack of scripts; see tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes #155. - Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter. - The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations. Note that we do *not* use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly. This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.
Update agenda-2018-06-15.md
5 participants
Fixes #78. Introduces the concept of a Script Record as a counterpart to a Module Record, and adds [[HostDefined]] fields to both of them. Every execution environment now has ScriptOrModule component pointing back to its "creator" script or module:
In the course of doing this, factored out ParseScript and ScriptEvaluation abstract operations, which now better parallel modules.
I think this is pretty good but review would be appreciated, especially where I converted ScriptEvaluation from Runtime Semantics into an abstract operation. The grammar interactions aren't 100% clear to me there.