ModuleDeclarationInstantiation behaviour after failure

[Jon Coppeard]

OK, this is great and I think it solves the problems of what to throw
away and not throwing away too much.

> 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?

Yes, this already has to happen to know when we can evaluate the
top-level module.

Thanks,

Jon

On 15/07/2016 18:31, Jason Orendorff wrote:
> 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
> <mailto: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