Add partial tests for import defer

[nicolo-ribaudo]

Plan: #4215 (I checked the checkbox for tests added by this PR)

This PR includes tests for:

• syntax
• Deferred namespace objects
• Behavior of synchronous and asynchronous deferred modules
• Errors for synchronous and asynchronous cases

I will open another PR (or push another commit here) for tests about async modules, since I still have to finish polishing it up.

There are a few details of the proposal that are still in flux because of some bugs, so this PR does not include tests for them:

• Symbol.toStringTag of deferred namespace objects
• test/language/import/import-defer/evaluation-sync/evaluation-* for the other object operations
• import.defer, which currently doesn't actually defer due to a problem with .then

[takikawa]

I tried running these in my WebKit implementation and found a few minor issues in the tests, such as missing module flags. This commit has the fixes I made: takikawa/WebKit@d536aa2

After the fixes I had about 8 failures but at least some of these are due to bugs in my implementation, I think.

[nicolo-ribaudo]

Thanks! I imported your patch.

After the fixes I had about 8 failures but at least some of these are due to bugs in my implementation, I think.

If you could share the list, I can double-check that the tests are correct.

(EDIT: Confirmed that they are bugs in Asumu's implementation)

[ptomato]

I haven't gotten most of the way through this, but here are some initial comments.

[ptomato]

Do we have a test elsewhere (not in syntax) that ensures this syntax is treated as a sync default binding named defer and not as a deferred import? e.g. the imported module performs a side effect that is tested for.

[nicolo-ribaudo]

No. Should I just add it in this file, given that we don't really have the concept of "syntax tests"?

[ptomato]

Sure, that would be fine too. By "in syntax" I meant in this syntax/ folder where the test is currently placed; if the test no longer purely tests syntax, you could move it, but I don't think it matters that much.

[ptomato]

For my own understanding, the URIError should be thrown regardless of whether this line is present, right?

Or maybe not, since the testing plan says "import and import defer + exec only execute the module once"

In any case, you should probably have both a .then and a .catch callback, and assert that only one is executed.

[nicolo-ribaudo]

This test for the following scenario:

• you get a deferred namespace of a module that has not been evaluated yet
• somebody else (in this case the dynamic import, but in the real world it will probably be a static import somewhere in another file) evaluates it. The test doesn't care about the details of this evaluation, just that it happens
• you try to access the deferred namespace you originally got a hold of, and it re-throws the error cached by the other evaluation

In the plan, it's "Property access re-throws the evaluation error > On first access for already evaluated modules"

[ptomato]

I would put an assertion in the catch callback to indicate what's supposed to happen — either it should not be called, or it should be called with an error. (This applies to other places in the PR too.)

[nicolo-ribaudo]

I noticed that I cannot use assert in _FIXTURE files (https://github.com/tc39/test262/blob/main/CONTRIBUTING.md#rules-for-module-_fixture-files). It's a bit weird because they are running in the same global scope as the non-fixture files, but I pushed a commit to fix it anyway.

[ptomato]

Thanks! In general these tests are pretty easy to read and understand.

There were some things that I think are errors in assertions, like the tags pushed to globalThis.evaluations in some cases, so if your implementation is passing these tests in their current state, you might want to check if that's correct.

[ptomato]

Is this order correct? It seems like the evaluation of the module should only happen during the evaluation of ns.foo in line 36, so in line 34 the error won't be present yet.
Additionally, do we not need to await Promise.resolve() in between evaluating ns.foo and checking for the TypeError, since the error will be caught in a microtask?

These comments may just be my misunderstanding of the proposal! I have similar comments on several other files which probably indicates that I'm missing some piece of comprehension.

(If I'm misunderstanding and microtasks in a deferred module import happen synchronously, then does this test and similar ones really need to be async though?)

[nicolo-ribaudo]

What is happening here is that ./dep_FIXTURE.js is not deferred, because it contains top-level await. So what is happening in this test is that:

• the deferred module is not actually deferred, so dep_FIXTURE.js starts executing and goes in its evaluating state
• it has access to a deferred namespace of itself
• once it reaches the await, the state changes to evaluating-async
• the test tries then to access a property from the deferred namespace while it's evaluating-async (which is what this test it testing). It should throw.
• dep_FIXTURE.js is done, and becomes evaluated
• main.js starts evaluating, and the error is already there
• ns.foo now works, because ns is evaluated and not evaluating-async

Should I put this comment in the "info" section, even if usually it just lists spec algorithms?

[ptomato]

Suggested change

	["dep", "tla-with-dep start", "tla-with-dep end"]
	["dep start", "tla-with-dep start", "tla-with-dep end"]

?

[ptomato]

I'm not sure I understand how we end up with this result. dep start and tla-with-dep start I get, because they are sync dependencies of imports-tla-with-dep_FIXTURE.js. But isn't tla-with-dep end only pushed after microtasks execute?

[nicolo-ribaudo]

Changed dep start to dep in dep_FIXTURE. As a rule, I'm using start/end for async modules (where the distinction is meaningful), and just the filename for sync modules.

I'm not sure I understand how we end up with this result. dep start and tla-with-dep start I get, because they are sync dependencies of imports-tla-with-dep_FIXTURE.js. But isn't tla-with-dep end only pushed after microtasks execute?

Due to the TLA, this file is equivalent to

import "./setup_FIXTURE.js";
import "./tla-with-dep_FIXTURE.js";
import defer * as ns from "./imports-tla-with-dep_FIXTURE.js";

assert.compareArray(
  globalThis.evaluations,
  ["dep", "tla-with-dep start", "tla-with-dep end"]
);
...

so main.js doesn't run until when tla-with-dep_FIXTURE.js is done running.

[nicolo-ribaudo]

Thanks both for the reviews :) Comments addressed.

[nicolo-ribaudo]

All fixed, thanks @takikawa!

[takikawa]

Aside from the flattening-order test which might need more adjustment, I ran the tests in JSC and saw 7 failures. I think these are likely all due to three existing issues with JSC's module loader (doesn't re-throw after exception during eval, module namespace object properties aren't writable, and certain cyclic module graphs cause debug assertions to fail) that aren't related to import defer.