You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a file with no dependencies, it's obvious that parse means that the error is thrown when calling ParseModule on its source code.
On the other hand, what happens when there are multiple files involved is less clear. Resolution of module dependencies is not defined in ECMA-262, but in HTML. Before the layering changes from 2022, there was a HostResolveImportedModule host hook that was responsible for loading/resolution of modules. There is also a ResolveExport AO, that might map to this "test262" resolution phase.
When running a test, there four possible phases:
module = ParseModule(): parse the entry module
module.LoadRequestedModules(): resolve, load and parse its dependencies
module.Link(): resolve the various exported and imported bindings
module.Evaluate(): executes the module and its dependencies
Before the 2022 layering changes, 1 and 2 where mixed together from an ECMA-262 point of view.
Using phase: parse for tests thrown during (2) prevents most JavaScript parsers from successfully using test262 as a test suite for parsing tests, since those projects would just call ParseModule( test source ) and would not proceed to (2)/(3)/(4). On the other hand, using phase: resolution for it seems wrong, since module resolution happens outside of ecma262 and thus we are probably testing binding resolution.
I propose that we clarify the following:
module = ParseModule() throws at phase: parse
module.LoadRequestedModules() doesn't have a corresponding phase, and we will make sure to write no tests that throw at this point.
module.Link() throws at phase: resolution
module.Evaluate() throws at phase: evaluation
The text was updated successfully, but these errors were encountered:
Use phase: resolution for test/language/import/import-assertions/json-invalid.js since we couldn't figure a use case to distinguish between your steps 2 and 3
Rewrite test/language/module-code/source-phase-import/import-source-binding-name.js as a fully passing test case by replacing '<do not resolve>' by a real fixture
https://github.com/tc39/test262/blob/main/CONTRIBUTING.md#negative
For a file with no dependencies, it's obvious that
parse
means that the error is thrown when callingParseModule
on its source code.On the other hand, what happens when there are multiple files involved is less clear. Resolution of module dependencies is not defined in ECMA-262, but in HTML. Before the layering changes from 2022, there was a
HostResolveImportedModule
host hook that was responsible for loading/resolution of modules. There is also aResolveExport
AO, that might map to this "test262" resolution phase.When running a test, there four possible phases:
module = ParseModule()
: parse the entry modulemodule.LoadRequestedModules()
: resolve, load and parse its dependenciesmodule.Link()
: resolve the various exported and imported bindingsmodule.Evaluate()
: executes the module and its dependenciesBefore the 2022 layering changes, 1 and 2 where mixed together from an ECMA-262 point of view.
Looking at current tests, it seems like:
phase: parse
phase: resolution
phase: evaluation
There is some confusion about (2):
./json-invalid_FIXTURE.json
, and it hasphase: parse
<do not resolve>
Using
phase: parse
for tests thrown during (2) prevents most JavaScript parsers from successfully using test262 as a test suite for parsing tests, since those projects would just callParseModule( test source )
and would not proceed to (2)/(3)/(4). On the other hand, usingphase: resolution
for it seems wrong, since module resolution happens outside of ecma262 and thus we are probably testing binding resolution.I propose that we clarify the following:
module = ParseModule()
throws atphase: parse
module.LoadRequestedModules()
doesn't have a corresponding phase, and we will make sure to write no tests that throw at this point.module.Link()
throws atphase: resolution
module.Evaluate()
throws atphase: evaluation
The text was updated successfully, but these errors were encountered: