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

[jmdyck]

There are various SDOs defined on the current forms of ImportCall, ImportDeclaration, and/or ExportDeclaration that are not defined on the new forms:

• BoundNames
• Evaluation
• ExportEntries
• ExportedBindings
• ExportedNames
• HasCallInTailPosition
• ImportEntries
• LexicallyScopedDeclarations
• ModuleRequests

[jmdyck]

I still think this should be marked type="definition" (and ecmarkup should be modified to treat it appropriately).

[jmdyck]

(Actually, at this point, even if ecmarkup isn't modified, the effect should be pretty minor, since AttributesKeyword is the only affected nonterminal now.)

[nicolo-ribaudo]

I will try to modify ecmarkup. It already supports duplicated definitions, but only in annexes.

[nicolo-ribaudo]

I pushed two new commits:

1. Validate attrs when lodaing deps and not when parsing fixes Invalid attributes keys in static imports should be a resolution/loading error and not a parsing error proposal-import-attributes#144. From an ECMA-262 point of view this is purely editorial, because:
   • it's not currently observable whether an error is thrown when parsing or when calling LoadImportedModules()
   • code that resulted in a syntax error still results in a syntax error, and vice versa. there might be a difference in the location of the reported syntax error (see the example in the linked issue), but that's already completely implementation-defined.
2. Merge AssertClause into WithClause, and fix missing SDOs while fixing Normative: Add Import Attributes #3057 (review) I realized that I had to duplicate every SDO using WithClause into exactly the same definition but using AssertClause. There are many of them, and copy-pasting risks introducing problems when we update one and forget to update the other one. I ended up merging the two productions as originally suggested by @bakkot in Normative: Add Import Attributes #3057 (comment), but with a production parameter to only allow assert in the [no LineTerminator here] case.

[jmdyck]

Why not just tweak @bakkot's suggestion into:

AttributesKeyword :
  `with`
  [no LineTerminator here] `assert`

That would eliminate the [DeprecatedAssert] parameter and the deprecated definitions of ImportDeclaration and ExportDeclaration.

[nicolo-ribaudo]

[no LineTerminator here] is never used at the beginning/end of a production currently, but if the editors like that I think it's a very good idea.

[nicolo-ribaudo]

I pushed @jmdyck's suggestion, to show how much it would simplify the spec.

[jmdyck]

[no LineTerminator here] is never used at the beginning/end of a production currently,

A [no LineTerminator here] constraint is similar in flavor to a [lookahead ...] constraint, and we have lots of occurrences of those at the start + end of productions (4 at the start, 24 at the end).

And there's nothing in the definition of [no LineTerminator here] that would preclude its use at the start/end of a production.

So I don't think we should have any qualms about using it in this way.

[jmdyck]

I think the ModuleRequests SDO needs rule(s) to handle:

`import` ModuleSpecifier WithClause? `;`

[jmdyck]

The form of this Let step is unusual. Normally, in Let _foo_ be <something>, the alias _foo_ doesn't appear in <something>.

For the 2 steps, maybe something more like:

1. Let _x_ be a List consisting of
     each LoadedModuleRequest Record _record_
     of _referrer_.[[LoadedModules]] such that etc.
3. Assert: _x_ has exactly one element.
4. Let _record_ be the sole element of _x_.

(That also eliminates the duplication between the two steps.)

[nicolo-ribaudo]

Uh ecmarkup's linting doesn't like this

[jmdyck]

Yeah, given

... a List consisting of each LoadedModuleRequest Record _r_
    of _referrer_.[[LoadedModules]] such that <condition>

ecmarkup is saying that it can't find a preceding declaration for _r_. That is, it's treating this occurrence of _r_ as a 'use', whereas it's syntactically a declaration.

@bakkot: could ecmarkup be modified to treat this as a declaration?

[jmdyck]

(Actually, at this point, even if ecmarkup isn't modified, the effect should be pretty minor, since AttributesKeyword is the only affected nonterminal now.)

[nicolo-ribaudo]

PR updated to remove support for float and bigint literal keys, as per consensus in the TC39 2023-09 meeting.