Normative: Add Import Attributes

[nicolo-ribaudo]

This proposal (https://tc39.es/proposal-import-attributes/, https://github.com/tc39/proposal-import-attributes) reached stage 3 during the March 2023 meeting, conditional on stage 3 reviews. I'm opening this PR before "real" stage 3 to help editors reviewing the full spec changes.

The proposal has already been integrated in HTML: https://html.spec.whatwg.org/#hostloadimportedmodule

PREVIEW: https://ci.tc39.es/preview/tc39/ecma262/pull/3057
DIFF: https://arai-a.github.io/ecma262-compare/?pr=3057 (note: the diff doesn't mark deprecated sections)

[nicolo-ribaudo]

@tc39/ecma262-editors Currently the only remaining condition for this proposal to be actually Stage 3 is the editorial review. It'd be great if you have time to do it :)

[bakkot]

LGTM other than comments.

[nicolo-ribaudo]

I pushed two more normative commits, that are oversights from the assert->with migration:

1. Added assert as an alternative to with also in export ... from statements
2. Removed the [no LineTerminator here] restriction before with

[linusg]

What's the status of this?

[bakkot]

@linusg It's stage 4, editors just haven't had time to get it landed yet.

[guybedford]

@bakkot thanks for the clarification - please just let us know if there's anything needed to help move this one along.

[jmdyck]

Looks okay to me.

(My analysis raised lots of complaints, but I think they're all false positives.)

[linusg]

It's now been four months since this reached stage 4 and there doesn't seem to be any movement still. Could we get an update from the editors when they plan to address this PR please?

• It's blocking Normative: Add JSON modules #3391 which is also stage 4
• I'm not sure about the exact cutoff date but it would be unfortunate if this doesn't make it into the ES 2025 snapshot despite being part of the language now
• I can't speak for any other small-scale engine implementors but personally I do want to implement both of these features but not before they have been integrated to avoid potential editorial churn

I'm not bringing this up formally at the upcoming plenary but I feel like there is a discussion to be had about requiring editorial sign-off before requesting stage 4 so that PRs can be merged without further thought afterwards.

[nicolo-ribaudo]

Note that this PR has LGTMs from Michael (#3057 (review)), Kevin (#3057 (review)) and jmdyck (#3057 (review)).

After Michael's and Kevin's LGTMs, there has been the change to delete the part about the "legacy assert keyword", so the PR needs another quick review, but it should be almost ready to land at this point.

[ljharb]

@linusg the cutoff is typically based on when stage 4 was achieved, and not based on when the PR is mergeable.

[linusg]

That's not what I mean - there will be a snapshot of the entire spec somewhere in the Ecma archives that says "this is ECMAScript 2025". If this PR is not merged by the time that snapshot is finalized import attributes and JSON modules won't be in there, despite having achieved stage 4. I was unable to find out when that happens exactly but I'm told it's around this time of the year.

[ljharb]

@linusg i'm the one who makes that snapshot, and it's never made until all outstanding stage 4 PRs are merged, so you don't have to worry about it.

[ljharb]

(it's also a living standard, so nobody should be caring about the snapshots, only what's merged into github :-) )

[linusg]

Absolutely, I don't use these snapshots ever. Still seemed worth pointing out to avoid this situation, thanks for clarifying!

[syg]

I think this lgtm. Some small editorial comments.

[nicolo-ribaudo]

I rebased on main and squashed and now esmeta is complaining, I'm checking why.

[nicolo-ribaudo]

[ParamTypeMismatch] Call[16128] argument assignment to second parameter _request_ when Call[16128] function call from Record[SourceTextModuleRecord].GetExportedNames (step 8.b, 19:43-93) to GetImportedModule
- expected: Record[ModuleRequestRecord]
- actual  : String
[ParamTypeMismatch] Call[16163] argument assignment to second parameter _request_ when Call[16163] function call from Record[SourceTextModuleRecord].ResolveExport (step 6.a.ii, 16:44-94) to GetImportedModule
- expected: Record[ModuleRequestRecord]
- actual  : String
[ParamTypeMismatch] Call[16178] argument assignment to second parameter _request_ when Call[16178] function call from Record[SourceTextModuleRecord].ResolveExport (step 9.b, 31:42-92) to GetImportedModule
- expected: Record[ModuleRequestRecord]
- actual  : String
[ParamTypeMismatch] Call[16215] argument assignment to second parameter _request_ when Call[16215] function call from Record[SourceTextModuleRecord].InitializeEnvironment (step 7.a, 13:42-93) to GetImportedModule
- expected: Record[ModuleRequestRecord]
- actual  : String

These are wrong. It thinks ExportEntry's [[ModuleRequest]] is a String, but this PR updates it to be a ModuleRequest Record.

[ParamTypeMismatch] Call[16296] argument assignment to first parameter _left_ when Call[16296] function call from FinishLoadingImportedModule (step 1.a, 3:105-151) to ModuleRequestsEqual
- expected: Record[LoadedModuleRequestRecord | ModuleRequestRecord]
- actual  : Record[{ Module : Record[ModuleRecord | ModuleRecordN], Specifier : String }]

This is also wrong. The actual type is LoadedModuleRequestRecord, declared in the line before.

[ParamTypeMismatch] Call[9455] argument assignment to first parameter _O_ when Call[9455] function call from EvaluateImportCall (step 11.d.iv.1, 28:35-54) to Get
- expected: Record[Object]
- actual  : ESValue
[ParamTypeMismatch] Call[9457] argument assignment to first parameter _O_ when Call[9457] function call from EvaluateImportCall (step 11.d.iv.2, 29:37-56) to Get
- expected: Record[Object]
- actual  : ESValue

These are because esmeta doesn't know that the entries of the list returned by EnumerableOwnProperties are arrays (thus objects).

[ReturnTypeMismatch] Block[9363] return statement in EvaluateImportCall (step 3, 4:36-73)
- expected: Normal[Record[Promise]] | Throw
- actual  : Return | Throw
[ReturnTypeMismatch] Block[9376] return statement in EvaluateImportCall (step 5.a, 7:36-71)
- expected: Normal[Record[Promise]] | Throw
- actual  : Return | Throw

This caught a bug! In case of import(yield), evaluating yield can return, thus EvaluateImportCall's type definition needs to allow Return completions.

I'll edit the PR fixing this last bug, and ignoring the other errors.

[nicolo-ribaudo]

If somebody with write access to this repo can force-push this PR to the import-attributes branch in this repo, I can rebase the json-modules PR on it.

[bakkot]

Done.