From 616df18cd9e6c17878db5167909c69ca9f9d2906 Mon Sep 17 00:00:00 2001 From: Domenic Denicola Date: Fri, 12 May 2017 12:59:57 -0400 Subject: [PATCH] Don't handle impossible errors in HostResolveImportedModule Several of the cases that were handled as errors are actually impossible to hit. Instead of throwing errors in these impossible situations, we can just assert that they are impossible. This also cleans up "resolve a module specifier" and the module map to be clear that they operate on URL records, not on absolute URL strings. Note that the remaining error case, of a null result in the module map, may go away, depending on how we fix #2629 and #2630. It currently occurs because of our strategy of calling ModuleDeclarationInstantiation() even when we know it will fail, in order to propagate errors, but that strategy is seeming increasingly unwise in the face of those bugs. --- source | 49 +++++++++++++++++++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 12 deletions(-) diff --git a/source b/source index 548f6e56cd9..f3aa4e028b1 100644 --- a/source +++ b/source @@ -87197,7 +87197,7 @@ interface NavigatorOnLine { a module specifier given module script and requested.

  • -

    If the result is error:

    +

    If url is failure:

    1. Let error be a new TypeError exception.

      2. @@ -88283,8 +88283,8 @@ document.querySelector("button").addEventListener("click", bound); scripts versus module scripts, since both of them use the script element.

      -

      A module map is a map of absolute URLs to values that are either a module script, null (used to +

      A module map is a map of URL records to values that are either a module script, null (used to represent failed fetches), or a placeholder value "fetching". Module maps are used to ensure that imported JavaScript modules are only fetched, parsed, and evaluated once per Document or

      To resolve a module specifier given a module script script - and a string specifier, perform the following steps. It will return either an - absolute URL or failure.

      + and a string specifier, perform the following steps. It will return either a URL + record or failure.

      1. Apply the URL parser to specifier. If the result is not failure, @@ -88410,14 +88410,39 @@ import "https://example.com/foo/../module2.js"; object's module map.

      2. Let url be the result of resolving a - module specifier given referencing module script and specifier. If - the result is failure, then throw a TypeError exception and abort these - steps.

        3. + module specifier given referencing module script and + specifier.

        -

      3. Let resolved module script be moduleMap[url]. If no such - entry exists, or if resolved module script is null or - "fetching", then throw a TypeError exception and abort these - steps.

        4. +

      4. Assert: url is never failure, because resolving a module specifier must have been previously successful with these + same two arguments during the appropriate invocation of fetch the descendants of and + instantiate a module script.

        5. + +

      5. Let resolved module script be moduleMap[url]. (This entry + must exist for us to have gotten to this point.)

        6. + +
      6. +

        If resolved module script is null, then throw a TypeError + exception and abort these steps.

        + +
        +

        This occurs when we have previously tried to fetch url, and failed, but are now rediscovering that fact in a new + module script graph. For example, given a file module.js whose contents + are

        + + 
        import "./404.js";
        + +

        then we could get here as part of fetching the + graph for the second script element in the following HTML:

        + + 
        <script type="module" src="404.js"></script>
+<script type="module" src="module.js"></script>
        +
        +
        7. + +

      7. Assert: resolved module script is a module script (i.e., is not + "fetching").

      8. If resolved module script's state is "errored", then throw