Chakracore: Implement Top-Level Await (Stage 3 proposal)

[fatcerberus]

Consider implementing top-level await, stage 3: https://github.com/tc39/proposal-top-level-await

I had misgivings about this, but it seems to have picked up traction recently and is already stage 3 so I doubt it's going anywhere, regardless of what I think of it. 😛

[rhuanjl]

I’ve been thinking about doing this for a while; but it would be a little messy and would likely involve internally treating any module containing Top Level Await as an asynchronous generator function.

Considering that my Async Geberator function implementation is still not enabled by default that could be problematic.

[fatcerberus]

Note that top-level await blocks execution of dependent module(s), unlike an async IIFE. Seems like that might make things tricky, too.

[rhuanjl]

I'll be happy to do this once #6312 has landed will be fairly simple.

[zenparsing]

@rhuanjl That will be awesome! I'll try to get #6312 merged over the next week.

[rhuanjl]

Further to my comment above I have now written an implementation of this, but it still needs some testing before it's ready to merge and it is based on top of #6312 so I cannot open a PR with it until that is merged. And I have on unsolved issue - error handling.

EDIT: Error handling
What should happen in the following case:

WScript.LoadModule(asyncModuleThatErrors);
import(asyncModuleThatErrors).then(/*do something here*/);

When a runtime method loads a module that errors the host should report an exception.

With dynamic import of a module that errors it should merely reject a promise which can be handled with a .then()

But what if the same module is subject to both? Which treatment should WIN when the resolution happens at the same time?

This is actually already an issue currently if you do:

WScript.RegisterModuleSource("modA", "throw new Error('BANG');");
import("modA");
WScript.LoadScriptFile("modA","module");

No error is reported. Whereas if you do:

WScript.RegisterModuleSource("modA", "throw new Error('BANG');");
WScript.LoadScriptFile("modA","module");

An error is reported.

The ModuleEvaluation method sets the runtime into exception state for an error thrown in a module if and only if that module (and its parents) have not been dynamically imported. The problem remains what to do if both treatments occur with the same module.

What should win AND should this be a question for the host or the engine. Also if it's a host question what info should the engine provide to enable the host to determine the treatment

[fatcerberus]

The fact that WScript.LoadScriptFile() doesn't return a promise complicates this IMO. I would expect the dynamic import() to still reject its promise (as this is well-defined by spec), but what should happen for the LoadScriptFile call is less clear and strikes me as a host-specific question.

[rhuanjl]

Implementation I've done is here https://github.com/rhuanjl/ChakraCore/tree/TopLevelAwait for anyone interested. I can't open a PR yet due to waiting on 6312 as mentioned above AND needing to set up some tests for it as well.

EDIT: I've run this against what I think are the relevant test262 tests, namely the contents of: https://github.com/tc39/test262/tree/master/test/language/module-code/top-level-await

Just 2 tests fail and neither relate to anything new with TLA:

1. early-errors-await-not-simple-assignment-target.js throws a Reference error instead of a syntax error - I believe this is due to this normative PR https://github.com/tc39/ecma262/pull/1527 that CC has not been updated for.
2. module-self-import-async-resolution-ticks.js fails to throw a reference error for the early access of 'self' - this is an existing issue that shows up in circular imports without top level await #3251

I still need to write some CC tests AND I'm nervous that the most likely source of any breakages (and hard crashes if any) will be cases with multiple root modules with shared children - the test262 cases don't cover these.