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]

What do we need this for?

[legendecas]

This is used to ensure that this file is been parsed as a script rather than a module. The file verifies that an import.source() call can be used in script code.

[nicolo-ribaudo]

It shuold be enough to not specify flags: [module] and the test will be pared as a script (by defaults tests are run as both strict and non-strict scripts, and this can be changed by specifying the noStrict/onlyStrict/module flags: https://github.com/tc39/test262/blob/main/INTERPRETING.md#flags).

[legendecas]

This case is adapted from https://github.com/tc39/test262/blob/main/src/dynamic-import/script-code-valid.case. I believe the intention here is to disallow this file to be accidentally parsed as a module code and pass the test as a false positive.

[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.

[guybedford]

Did you mean 0 not 0F in the comment?