[Webkit-unassigned] [Bug 190843] New: Rejected dynamic import should be consistent on the success/failure paths

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=190843

            Bug ID: 190843
           Summary: Rejected dynamic import should be consistent on the
                    success/failure paths
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: leo at bocoup.com

>From the spec proposal for `import()`:

https://tc39.github.io/proposal-dynamic-import/#sec-hostimportmoduledynamically

---
Failure path:
- At some future time, the host environment must perform FinishDynamicImport(referencingScriptOrModule, specifier, promiseCapability, an abrupt completion), with the abrupt completion representing the cause of failure.

The intent of this specification is to not violate run to completion semantics. The spec-level formalization of this is a work-in-progress.

Every call to HostImportModuleDynamically with the same referencingScriptOrModule and specifier arguments must conform to the same set of requirements above as previous calls do. That is, if the host environment takes the success path once for a given referencingScriptOrModule, specifier pair, it must always do so, and the same for the failure path.
---

So if I have 2 import calls to the same pair of referencingScriptorModule and specifier, and if they go to a failure path from the evaluation of a module by an evaluation abrupt completion, JSC should keep it consistent:

```
async function fn() {
    let err;
    let result = {};
    const keep = result;
    try {
        result = await import('./poisoned.js');
    } catch (error) {
        err = error;
    }
    assert.sameValue(err, 'foo', 'first evaluation should be an abrupt completion');
    assert.sameValue(result, keep, 'result should not be set');

    err = undefined;

    try {
        result = await import('./poisoned.js');
    } catch (error) {
        err = error;
    }

    assert.sameValue(result, keep, 'result should still be the same as keep');
    assert.sameValue(err, 'foo', 'second evaluation should repeat the same abrupt completion');
}

fn().then($DONE, $DONE);
```

the problem here is, the second import to the same poisoned module should repeat the same rejection, summarizing:

```
import('./poisoned.js'); // rejected promise
import('./poisoned.js'); // should also be a rejected promise, but JSC is fulfilling it
```

In that way, I get the second try catch to continue the evaluation up to setting the resolved value to `result`, which is a namespace object created from `./poisoned.js`.

Let's say this is my poisoned module:

```
export var x = 1;
throw 'foo';
export var y = 2;
```

The resolved namespace object is giving me the x and y exported names, with x set to 1, and y being undefined.

---

The expected result should be a rejected promise like on the import() usage.

I'm currently adding tests to cover this on Test262, I hope it helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181023/b89d6298/attachment.html>