Add tests for Source Phase Imports

[legendecas]

Add tests for Source Phase Imports, ecma262 PR.

[nicolo-ribaudo]

We should also add a test to verify that the import source declaration syntax is supported:

// test.js
import source x from "x";
import "./ensure-linking-error_FIXTURE.js";

throws in the resolution phase and not in the parse phase (e.g. https://github.com/tc39/test262/blob/main/INTERPRETING.md#negative)

where that fixture file is https://github.com/tc39/test262/blob/main/test/language/module-code/import-attributes/ensure-linking-error_FIXTURE.js

--

We should also test that Source Text Module Records do not have a source representation:

assertRejects(import("./a-js-file_FIXTURE.js"), ReferenceError);

// negative:
// - phase: resolution
// - type: ReferenceError
import source s from "./a-js-file_FIXTURE.js";

[nicolo-ribaudo]

cc @guybedford

[guybedford]

Appreciated for your patience with the review. Finally had a look through and it's seeming really thorough to me.

Perhaps we should move abstract-module-source and its prototype tests to test/built-ins?

The invalid and valid tests could also include a test that import.source cannot be assigned. See some of the import.meta tests for examples. We could also ensure import.source.x, typeof import.source etc remains invalid.

I would note that we are still aiming to specify import.source for ECMAScript SourceText module records, so that reducing the number of tests that would need to change / be removed when that happens would be useful. Rather than the suite of these failures in the catch tests I think just a few would suffice if they will be changed anyway.

Finally for the static import syntax tests, it might be beneficial to also include some of the valid cases of the source and from identifier names being imported for the source import phase per the various discussions we had around these syntax cases.

[legendecas]

@guybedford thanks for the suggestions, updated!

[legendecas]

This PR doesn't include import-attributes with source phase imports. Once it is normatively specified, the test can be added as well.

[nicolo-ribaudo]

Why do we need this first one?

[nicolo-ribaudo]

There is no requirement that an empty specifier will fail resolving. Can we use something like from '<do not resolve>', and explicitly document it in https://github.com/tc39/test262/blob/main/INTERPRETING.md?