Normative: Prevent DFS invariants from being broken

[devsnek]

An implementation of HostImportModuleDynamically, could, in theory, call
Evaluate() in the same tick as the call to HostImportModuleDynamically.
If that call to HostImportModuleDynamically was the direct result of
another call to Evaluate(), this may eagerly evaluate a module that
is already queued to be run at a later time.

cc @guybedford

[guybedford]

This is a really important invariant of the DFS algorithm not to be interrupted during its search by another search, as the algorithm isn't designed to run in parallel with other algorithms.

This is also an important invariant for the top-level await spec too.

[Ms2ger]

This makes sense to me.

[littledan]

Should we make this a requirement on host environments, in addition to an assertion?

[domenic]

LGTM. @littledan's suggestion also makes sense, but I think without #735 (or some other acknowledgment of the fact that hosts are actually going to be the ones driving module evaluation), it's unclear where to put such a requirement.

[ljharb]

@devsnek @guybedford any update on the test262 tests for this change, or, alternatively, a persuasive explanation of why this is untestable?

[devsnek]

I don't think we can create tests that exhaustively prove this invariant is held. We might be able to add a small test for a case where import() runs synchronously(??).

[ljharb]

That'd be great!

[devsnek]

Test: tc39/test262#2506