GetModuleNamespace has an incorrect assertion

[jorendorff]

According to this bug:

In https://tc39.github.io/ecma262/#sec-getmodulenamespace, the assertion in step 3

3. Assert: If module.[[Status]] is "evaluated", module.[[EvaluationError]] is undefined.

is incorrect.

Test case using the dynamic import() proposal which results in the same spec assertion.

m.js

import("./a.js");
import("./b.js");

a.js:

throw undefined;

b.js:

import * as ns0 from "./a.js";

[allenwb]

I think every place in spec. text that talks about execution values and might be using undefined as a marker for no exception needs to be examined.

I know I never considered the possibility somebody might actually do throw undefined;

[allenwb]

I think every place in spec. text that talks about execution values and might be using undefined as a marker for no exception needs to be examined.

I know I never considered the possibility somebody might actually do throw undefined;

[domenic]

In the case you mention [[EvaluationError]] will not be undefined. It will be Completion{[[Type]]: throw, [[Target]]: empty, [[Value]]: undefined}.

[domenic]

In the case you mention [[EvaluationError]] will not be undefined. It will be Completion{[[Type]]: throw, [[Target]]: empty, [[Value]]: undefined}.

[littledan]

I share @domenic's reading. Should we just close this issue?

[littledan]

I share @domenic's reading. Should we just close this issue?

[anba]

No. This issue also applies when other things are thrown, e.g. throw new Error;.

import("./a.js"); and import("./b.js"); result in two distinct module declaration and module evaluation passes. After the pass for import("./a.js"); has finished, the module state for the a.js module is [[Status]] = "Evaluated" and [[EvaluationError]] contains an abrupt completion record. So when 15.2.1.16.4.2 ModuleDeclarationEnvironmentSetup for b.js is executed, 15.2.1.16.4.2 step 8.c.i will call 15.2.1.18 GetModuleNamespace for a.js. And then the assertion in 15.2.1.18 step 3 will fire, because [[EvaluationError]] for a.js is not undefined.

[anba]

No. This issue also applies when other things are thrown, e.g. throw new Error;.

import("./a.js"); and import("./b.js"); result in two distinct module declaration and module evaluation passes. After the pass for import("./a.js"); has finished, the module state for the a.js module is [[Status]] = "Evaluated" and [[EvaluationError]] contains an abrupt completion record. So when 15.2.1.16.4.2 ModuleDeclarationEnvironmentSetup for b.js is executed, 15.2.1.16.4.2 step 8.c.i will call 15.2.1.18 GetModuleNamespace for a.js. And then the assertion in 15.2.1.18 step 3 will fire, because [[EvaluationError]] for a.js is not undefined.

[GeorgNeis]

Yes, the assertion is incorrect. I believe it's safe to remove it.

[GeorgNeis]

Yes, the assertion is incorrect. I believe it's safe to remove it.

[littledan]

Thanks for explaining. Does anyone want to make a PR to remove the assertion?

[littledan]

Thanks for explaining. Does anyone want to make a PR to remove the assertion?