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

HostResolveImportedModule asserting _resolved module script_'s instantiation state is "instantiated" does not necessarily hold in cyclic module graph #2596

Closed
nyaxt opened this issue Apr 26, 2017 · 2 comments
Assignees

Comments

@nyaxt
Copy link
Member

nyaxt commented Apr 26, 2017

HostResolveImportedModule Step 6 says:

Assert: resolved module script's instantiation state is "instantiated" (and thus its module record is not null).

However, this doesn't always hold when fetching module graph with cycles.

@nyaxt
Copy link
Member Author

nyaxt commented Apr 26, 2017

Consider a case where we have: module A -dep-> module B -dep-> moduleA.

  • We start from "fetch a module script graph" for A, which
  • performs internal module graph fetching procedure for A, which
  • fetches and compiles itself, and
  • finds out module B as its descendants, and trigger the internal module graph fetching procedure for B, which
    • finds out module A as its descendants, but as module A is in the ancestor list, we stop recursion here.
    • then calls B's record.ModuleDeclarationInstantiation()
      • which will HostResolveImportedModule A
      • which resolves to module script A's record
      • however module script A isn't "instantiated" yet!

@domenic domenic self-assigned this Apr 26, 2017
@domenic
Copy link
Member

domenic commented Apr 26, 2017

This seems correct. I think what I should be asserting is simply that its module record is not null.

domenic added a commit that referenced this issue Apr 28, 2017
For cyclic module graphs, this assert is overzealous; this adjusts it
to assert only what we need. Closes #2596.
domenic added a commit that referenced this issue May 1, 2017
For cyclic module graphs, this assert is overzealous; this adjusts it
to assert only what we need. Closes #2596.
scheib pushed a commit to scheib/chromium that referenced this issue May 2, 2017
Before this CL, ScriptModuleResolverImpl::Resolve wrongly assumed that
resolved module script's instantiation state is always "instantiated".
However, this isn't always the case when instantiating module graph w/
cycles.

This CL removes the CHECK.

Corresponding spec PR: whatwg/html#2603

BUG=594639, whatwg/html#2596
TEST=external/wpt/html/semantics/scripting-1/the-script-element/module/imports.html shouldn't crash

Review-Url: https://codereview.chromium.org/2848213002
Cr-Commit-Position: refs/heads/master@{#468555}
inikulin pushed a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017
For cyclic module graphs, this assert is overzealous; this adjusts it
to assert only what we need. Closes whatwg#2596.
inikulin pushed a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017
For cyclic module graphs, this assert is overzealous; this adjusts it
to assert only what we need. Closes whatwg#2596.
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
For cyclic module graphs, this assert is overzealous; this adjusts it
to assert only what we need. Closes whatwg#2596.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants