-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Do not remember module instantiation errors. #1006
Conversation
😀 |
Give me a little bit to read through the diff but the approach seems fine. |
…iation errors Today, we are in somewhat stale state where new module tree fetching algorithm [1][2] is partially applied. This CL (temporarily) disables an assert which exists in the final algorithm, but doesn't hold today. Specifically, the assert in HostResolveImportedModule (HRIM [3]) Step 7 currently doesn't hold, as the instantiation may have failed for a module script node, and current V8 implementation records the instantiation error as an error. See the attached test case for an example. [1] whatwg/html#2991 [2] tc39/ecma262#1006 [3] https://html.spec.whatwg.org/multipage/webappapis.html#hostresolveimportedmodule(referencingscriptormodule,-specifier) Test: external/wpt/html/semantics/scripting-1/the-script-element/module/instantiation-error-8.html Bug: 772750, 763597 Change-Id: Ida600598b658c74cdbda5937219f1e62a41f2a16
…iation errors Today, we are in somewhat stale state where new module tree fetching algorithm [1][2] is partially applied. This CL (temporarily) disables an assert which exists in the final algorithm, but doesn't hold today. Specifically, the assert in HostResolveImportedModule (HRIM [3]) Step 7 currently doesn't hold, as the instantiation may have failed for a module script node, and current V8 implementation records the instantiation error as an error. See the attached test case for an example. [1] whatwg/html#2991 [2] tc39/ecma262#1006 [3] https://html.spec.whatwg.org/multipage/webappapis.html#hostresolveimportedmodule(referencingscriptormodule,-specifier) Test: external/wpt/html/semantics/scripting-1/the-script-element/module/instantiation-error-8.html Bug: 772750, 763597 Change-Id: Ida600598b658c74cdbda5937219f1e62a41f2a16 Reviewed-on: https://chromium-review.googlesource.com/708078 Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#507888}
…iation errors Today, we are in somewhat stale state where new module tree fetching algorithm [1][2] is partially applied. This CL (temporarily) disables an assert which exists in the final algorithm, but doesn't hold today. Specifically, the assert in HostResolveImportedModule (HRIM [3]) Step 7 currently doesn't hold, as the instantiation may have failed for a module script node, and current V8 implementation records the instantiation error as an error. See the attached test case for an example. [1] whatwg/html#2991 [2] tc39/ecma262#1006 [3] https://html.spec.whatwg.org/multipage/webappapis.html#hostresolveimportedmodule(referencingscriptormodule,-specifier) Test: external/wpt/html/semantics/scripting-1/the-script-element/module/instantiation-error-8.html Bug: 772750, 763597 Change-Id: Ida600598b658c74cdbda5937219f1e62a41f2a16 Reviewed-on: https://chromium-review.googlesource.com/708078 Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#507888}
…iation errors Today, we are in somewhat stale state where new module tree fetching algorithm [1][2] is partially applied. This CL (temporarily) disables an assert which exists in the final algorithm, but doesn't hold today. Specifically, the assert in HostResolveImportedModule (HRIM [3]) Step 7 currently doesn't hold, as the instantiation may have failed for a module script node, and current V8 implementation records the instantiation error as an error. See the attached test case for an example. [1] whatwg/html#2991 [2] tc39/ecma262#1006 [3] https://html.spec.whatwg.org/multipage/webappapis.html#hostresolveimportedmodule(referencingscriptormodule,-specifier) Test: external/wpt/html/semantics/scripting-1/the-script-element/module/instantiation-error-8.html Bug: 772750, 763597 Change-Id: Ida600598b658c74cdbda5937219f1e62a41f2a16 Reviewed-on: https://chromium-review.googlesource.com/708078 Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#507888}
This looks good. Especially appreciate the updated copy in 15.2.1.16.6 Example Source Text Module Record Graphs. I introduced a merge conflict - will attempt to resolve soon unless someone beats me to it. |
5408ef3
to
8bc7f46
Compare
Alright I think I rebased correctly. @GeorgNeis @domenic could one of you take a quick look and make sure I didn't hose anything? |
LGTM |
…iation errors Today, we are in somewhat stale state where new module tree fetching algorithm [1][2] is partially applied. This CL (temporarily) disables an assert which exists in the final algorithm, but doesn't hold today. Specifically, the assert in HostResolveImportedModule (HRIM [3]) Step 7 currently doesn't hold, as the instantiation may have failed for a module script node, and current V8 implementation records the instantiation error as an error. See the attached test case for an example. [1] whatwg/html#2991 [2] tc39/ecma262#1006 [3] https://html.spec.whatwg.org/multipage/webappapis.html#hostresolveimportedmodule(referencingscriptormodule,-specifier) Test: external/wpt/html/semantics/scripting-1/the-script-element/module/instantiation-error-8.html Bug: 772750, 763597 Change-Id: Ida600598b658c74cdbda5937219f1e62a41f2a16 Reviewed-on: https://chromium-review.googlesource.com/708078 Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#507888}
A while ago, we changed the specification of modules such that instantiation and evaluation errors are recorded and then re-thrown by later instantiation/evaluation attempts. We have since realized that, in the case of instantiation errors, this was not a good idea, as it does not give us the kind of determinacy that we want.
The problem has to do with instantiating multiple "root" modules in a non-deterministic order, which happens e.g. due to multiple
<script type=module ...>
elements or multipleimport()
expressions. What we want to guarantee is at least "blame determinism", i.e., no matterat which point an instantiation happens, if it fails then the error always originates from the same importing statement.
In cyclic graphs, having a failed instantiation record the error is in conflict with this goal. Consider this example:
If A gets instantiated first, both script loads result in an error blaming B's import of "something_else". If B gets instantiated first, both loads result in an error blaming A's import of "something".
Our solution is simply to not record instantiation errors but instead reset a module to "uninstantiated" if instantiation fails. In the example above, the load of A will then result in an error blaming B's import of "something_else", and the load of B will result in an error blaming A's import of "something" --- no matter which one gets instantiated first. (The error objects are not identical. While it's possible to enforce even this, it would require significant extra complexity, which
is why we decided against it.)
The treatment of evaluation errors remains unchanged: unlike instantiation, evaluation must not happen more than once, and is not idempotent, so we definitely need to record the error there. (See
launchTheMissiles()
in #862.)Summary of the changes proposed in this PR:
Main changes:
Minor changes include:
[[EvaluationError]].
Related pull request for HTML: whatwg/html#2991