Layering: Add HostLoadImportedModule hook

[nicolo-ribaudo]

This PR also removes the HostResolveImportedModule and HostImportModuleDynamically hooks.

A few comments/questions:

1. ContinueDynamicImport is kinda messy, with all the closures and PerformPromiseThen. Is it ok to extend AsyncBlockStart like in https://tc39.es/proposal-array-from-async/#sec-asyncblockstart so that I can use the Await macro?
2. ResolveExport is described as returning null or something, but it can also return a throw completion (if it's called on a module that re-exports from a dependency that hasn't been already loaded - NOTE: this can only happen if a host calls ResolveExport() even if LoadRequestedModules() doesn't succeed, and they don't have any good reason to do so). This was the behavior even before this PR.
   • Is it ok?
   • Should we make it return null?
   • Should we require that it's called only after having loaded the dependencies?
3. I named the new Module Records method LoadRequestedModules() to match the name of the [[RequestedModules]] slot, but maybe LoadImportedModules() or LoadDependencies() are better?
4. I find the hostDefined parameter of LoadRequestedModules() to be incredibly ugly, but it's needed by HTML to pass some context only to modules imported in "the current loading process" and not in "future loading processes" (the .destination flag it sets on the Request object it creates to fetch modules). It's possible that one day HTML will align requests of static and dynamic imports, but today is not that day yet.
5. I tracked the loading state across the ecma262-host-ecma262 round trip using a ModuleLoadState record, which is overloaded for two usages that are distinguished using an [[Action]] enum field. Is it ok, or should I split it into two different record types (GraphLoadingState and DynamicImportState)? (related: Layering: Add HostLoadImportedModule hook #2905 (comment))

The HTML PR is whatwg/html#8253. Today's consensus was based on the fact that this refactor is purely editorial for the ECMA-262+(insert known host here) pair, so I would like to get a full review on the HTML side to check if we need any tweaks before moving on with this PR. EDIT: Got a 👍 from the HTML side.

[nicolo-ribaudo]

The HTML side of this refactor is starting to get reviewed, I would love to receive a review for this PR too!

[guybedford]

It's possible that one day HTML will align requests of static and dynamic imports, but today is not that day yet.

Would be interested to hear more!

ResolveExport is described as returning null or something, but it can also return a throw completion (if it's called on a module that re-exports from a dependency that hasn't been already loaded - NOTE: this can only happen if a host calls ResolveExport() even if LoadRequestedModules() doesn't succeed, and they don't have any good reason to do so):

I don't think there is any real-world expectation that has ever relied upon ResolveExport throwing, so my preference would be turning this into an internal assertion and enforcing the behaviour that it is only ever called on loaded modules. Is that possible to do?

[guybedford]

In the case where a module has already been loaded, is it up to the host whether it resolves synchronously or asynchronously? I wonder if we should mandate already-loaded modules return synchronously to avoid unnecessary divergence?

[nicolo-ribaudo]

Until last week the HTML spec was ambiguous and allowed loading of already-loaded modules to be asynchronous. I updated that spec to make it synchronous, but without first discussing it with implementers, and browsers don't currently agree.

I'm working on it in web-platform-tests/wpt#35949, but I prefer to keep it out of this PR (since the consensus was based on the fact that this was not observably normative in common hosts).

[guybedford]

Glad to hear you're working on it!

[guybedford]

Do we really need a separate [[IsLoading]] state if it is equivalent to checking [[PendingModules]] > 0?

[nicolo-ribaudo]

It's not equivalent if the host calls FinishLoadingImportedModule with a throw completion: there might still be pending modules, but we stop the loading process.

[jmdyck]

Oh, I forgot to say: This PR undefines the ids:

• sec-hostresolveimportedmodule
• sec-hostimportmoduledynamically
• sec-finishdynamicimport

which should maybe become oldids.

[nicolo-ribaudo]

Thanks for the review @jmdyck! I added sec-hostresolveimportedmodule/sec-hostimportmoduledynamically as oldids of HostLoadImportedModule, and sec-finishdynamicimport as oldids fo FinishLoadingImportedModule. However, I'm not sure if it's correct because those aren't just renames but completely new AOs.

[nicolo-ribaudo]

@tc39/ecma262-editors is there anything I could do to help moving this PR forward? There are a bunch of proposals that needs to be updated on top of this, so having it reviewed&merged would be nice.

There are some editorial questions I have (in the issue description), and you can probably give your opinion on them just reading the new spec text without first doing a deep review, so that I can start resolving them :)

[syg]

@nicolo-ribaudo We discussed some of your questions on the editor call, our preferences are:

1. We have plans eventually to basically have asynchronous Abstract Closures. For now, since you already wrote the manual promise-handler version, just keep it as is, we'll simplify this when we introduce the ability to have async ACs.

2. We don't quite grok the scenario you're describing. Are you saying the only reason this method would throw today is if a host calls it in a weird way that no host actually does? If so, please help us confirm if that's the case, and once confirmed, we should add assertions and make the method infallible.

3. Name sounds good.

4. More of a comment than a question? Let's keep the host-defined.

5. Please name and split them into two separate Record types. Get rid of [[Action]] and just query for if the record is one of the specific record types.

[nicolo-ribaudo]

@jmdyck Done, thanks!

[nicolo-ribaudo]

Regarding the IPR failure: I originally signed the IPR form with my personal email, but I have committed with my Igalia email. I'll fix it.

EDIT: It looks like the failure is not related? It says "Missing 1 authors: tobie"

[michaelficarra]

@nicolo-ribaudo Can you try rebasing on main?

[nicolo-ribaudo]

Still failing, maybe because Tobie left google (or at least, it's not linked anymore in his GitHub profile)?

[ljharb]

@nicolo-ribaudo ill take a look at it

[ljharb]

It's very strange; the passing tests found 146 authors, in the last day or two it's found 147 including tobie. I'll fix it by adding them to the Emeriti team, since they were employed at Google at the time.

[nicolo-ribaudo]

Thanks @ljharb :)

@jmdyck done!

addressed