ModuleDeclarationInstantiation behaviour after failure

[Jason Orendorff]

How about this: Linking happens as eagerly as possible whenever a module
arrives off the network. This means that very often we'll be linking one
module at a time. In any case, every link set will be a strongly connected
component of ready-to-link modules in the dependency graph; and therefore
if linking fails, we should discard all the modules that we were trying to
link.

When a link error or any other error happens, we immediately discard the
failed module and everything that depends on it (potentially many modules
in various states, etc.). Implementing this efficiently means tracking, for
each module, "all the stuff that's depending/waiting on me". But the loader
has to do this anyway, right?

More complete description of this proposal, in case that's not clear:
https://gist.github.com/jorendorff/fc5bad969137402caa10bb3570b3f202

On Fri, Jul 15, 2016 at 9:32 AM, Jon Coppeard <jcoppeard at mozilla.com> wrote:

> Another similar approach that also uses the committed state might be to
> parse all modules as they become available and discard any uncommitted
> dependencies on instantiation error.


What I'm proposing doesn't discard in-flight dependencies, but allows them
to finish loading.

However that still has the disadvantage that too many modules are thrown
> away on error.


Agreed.


> I guess what I'd really like is some support for this simultaneous
> loading in ES.


At the least, I think it makes sense to mark Module Records for modules
that failed to parse or link as permanently bad, and assert as we go that
we are only ever working on good Module Records. It would be a nice
clarification. (I suspect TC39 would accept patches for this, even though
the status quo seems correct in every way -- it's just a matter of someone
doing the work.)

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160715/7a1b8489/attachment-0001.html>