ModuleDeclarationInstantiation behaviour after failure

[Caridy Patiño]

Moving step 7 to the end is not an option since the primary use of that step is to support circular references.

As for recovering from errors, this is in the realm of the loader and the registry to prevent subsequence attempts to instantiate a source text module record that failed already. There is not such things are a recovery from a failure in a module, just like there is none on a script. A testament of this is that a module record never holds a reference to another module record, it always resolve it when needed.

/caridy

> On Jul 6, 2016, at 6:02 AM, Jon Coppeard <jcoppeard at mozilla.com> wrote:
> 
> Fuzz testing has recently turned up some interesting behaviour involving
> ModuleDeclarationInstantiation.
> 
> What currently happens is that ModuleDeclarationInstantiation always
> initialises the source text module record's Environment slot, even if it
> subsequently fails with an error (e.g. failure to resolve import).  This
> leaves the environment partially initialised.
> 
> Then if it is called a second time for that module (maybe in the course
> of recursively performing ModuleDeclarationInstantiation starting from a
> different module) it will succeed without doing anything.  This can lead
> to failure further on when code is executed without the expected
> bindings being present.
> 
> Is this expected?
> 
> It seems to me that a subsequent call should either attempt to create
> the environment again (maybe all dependencies are now available?) or
> fail immediately in the same way.
> 
> The former could be accomplished by only setting the Environment slot at
> the end after the environment has been successfully initialised.
> 
> Jon
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss