test262/test/language/module-code/instn-star-props-dflt-skip.js

46 lines
1.4 KiB
JavaScript
Raw Normal View History

Module semantics: declaration instantiation Files whose name ends in `_.js` are not themselves valid Test262 tests and should not be interpreted as such by test runners. --- Because the tests in this patch concern declaration *instantiation*, care has been taken to avoid asserting binding values following evaluation. Because a given module's dependencies are evaluated prior to the module itself, this is only observable in modules which import their own bindings. A separate patch dedicated to the evaluation of module code asserts the behavior of bindings following evaluation. --- For tests that concern the creation of a module namespace object, this patch relies on the semantics of the `in` operator. The `in` operator uses the [[HasProperty]] internal method and avoids testing unrelated semantics concerning binding resolution. Those semantics should be explicitly asserted with a separate set of tests dedicated to that purpose. --- One test case which is notably missing is error resulting from a cycle due to an `import` declaration (under the current file naming scheme, such a test might be named `instn-named-err-circular.js`). Due to the recursive nature of ModuleDeclarationInstantiation, it is not technically possible for a circular request to be found in step 12.c.i. Cycles rely on at least 2 `export` declarations, and because these are resolved *before* imports, any cycle would trigger failure prior to step 12.c. --- One aspect of *module* resolution that makes ordering observable is the fact that resolution can fail in two distinct ways (i.e. with a SyntaxError or with a ReferenceError). This patch includes tests that leverage this detail in order to assert that modules are resolved in the correct sequence. However, from the perspective of the ECMA-262 specification, the ordering of *export* (e.g. binding) resolution is not observable. This is due to restrictions on the grammar, where each export is independent. When *export* resolution fails, it does so with instances of SyntaxError alone, precluding the above strategy. So while ModuleDeclarationInstantiation resolves the exports of the module's dependencies in the following order: 1. "Indirect" exports, e.g. - `export { x } from './y.js';` - `export { x as z } from './y.js';` - `import { x } from './y.js'; export { x };` 2. "Star" imports - `import * as ns from './y.js';` 3. "Named" (my word) imports - `import x from './y.js';` - `import { x } from './y.js';` - `import { x as z } from './y.js';` Intentional failures cannot be used to discern resolution ordering.
2016-03-29 17:50:15 +02:00
// Copyright (C) 2016 the V8 project authors. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/*---
description: >
Module semantics: declaration instantiation Files whose name ends in `_.js` are not themselves valid Test262 tests and should not be interpreted as such by test runners. --- Because the tests in this patch concern declaration *instantiation*, care has been taken to avoid asserting binding values following evaluation. Because a given module's dependencies are evaluated prior to the module itself, this is only observable in modules which import their own bindings. A separate patch dedicated to the evaluation of module code asserts the behavior of bindings following evaluation. --- For tests that concern the creation of a module namespace object, this patch relies on the semantics of the `in` operator. The `in` operator uses the [[HasProperty]] internal method and avoids testing unrelated semantics concerning binding resolution. Those semantics should be explicitly asserted with a separate set of tests dedicated to that purpose. --- One test case which is notably missing is error resulting from a cycle due to an `import` declaration (under the current file naming scheme, such a test might be named `instn-named-err-circular.js`). Due to the recursive nature of ModuleDeclarationInstantiation, it is not technically possible for a circular request to be found in step 12.c.i. Cycles rely on at least 2 `export` declarations, and because these are resolved *before* imports, any cycle would trigger failure prior to step 12.c. --- One aspect of *module* resolution that makes ordering observable is the fact that resolution can fail in two distinct ways (i.e. with a SyntaxError or with a ReferenceError). This patch includes tests that leverage this detail in order to assert that modules are resolved in the correct sequence. However, from the perspective of the ECMA-262 specification, the ordering of *export* (e.g. binding) resolution is not observable. This is due to restrictions on the grammar, where each export is independent. When *export* resolution fails, it does so with instances of SyntaxError alone, precluding the above strategy. So while ModuleDeclarationInstantiation resolves the exports of the module's dependencies in the following order: 1. "Indirect" exports, e.g. - `export { x } from './y.js';` - `export { x as z } from './y.js';` - `import { x } from './y.js'; export { x };` 2. "Star" imports - `import * as ns from './y.js';` 3. "Named" (my word) imports - `import x from './y.js';` - `import { x } from './y.js';` - `import { x as z } from './y.js';` Intentional failures cannot be used to discern resolution ordering.
2016-03-29 17:50:15 +02:00
Default exports are not included in the module namespace object
esid: sec-moduledeclarationinstantiation
info: |
[...]
12. For each ImportEntry Record in in module.[[ImportEntries]], do
a. Let importedModule be ? HostResolveImportedModule(module,
in.[[ModuleRequest]]).
b. If in.[[ImportName]] is "*", then
i. Let namespace be ? GetModuleNamespace(importedModule).
[...]
15.2.1.18 Runtime Semantics: GetModuleNamespace
[...]
3. If namespace is undefined, then
a. Let exportedNames be ? module.GetExportedNames(« »).
[...]
15.2.1.16.2 GetExportedNames
[...]
7. For each ExportEntry Record e in module.[[StarExportEntries]], do
[...]
c. For each element n of starNames, do
i. If SameValue(n, "default") is false, then
[...]
flags: [module]
---*/
import * as named from './instn-star-props-dflt-skip-star-named_FIXTURE.js';
import * as production from './instn-star-props-dflt-skip-star-prod_FIXTURE.js';
Module semantics: declaration instantiation Files whose name ends in `_.js` are not themselves valid Test262 tests and should not be interpreted as such by test runners. --- Because the tests in this patch concern declaration *instantiation*, care has been taken to avoid asserting binding values following evaluation. Because a given module's dependencies are evaluated prior to the module itself, this is only observable in modules which import their own bindings. A separate patch dedicated to the evaluation of module code asserts the behavior of bindings following evaluation. --- For tests that concern the creation of a module namespace object, this patch relies on the semantics of the `in` operator. The `in` operator uses the [[HasProperty]] internal method and avoids testing unrelated semantics concerning binding resolution. Those semantics should be explicitly asserted with a separate set of tests dedicated to that purpose. --- One test case which is notably missing is error resulting from a cycle due to an `import` declaration (under the current file naming scheme, such a test might be named `instn-named-err-circular.js`). Due to the recursive nature of ModuleDeclarationInstantiation, it is not technically possible for a circular request to be found in step 12.c.i. Cycles rely on at least 2 `export` declarations, and because these are resolved *before* imports, any cycle would trigger failure prior to step 12.c. --- One aspect of *module* resolution that makes ordering observable is the fact that resolution can fail in two distinct ways (i.e. with a SyntaxError or with a ReferenceError). This patch includes tests that leverage this detail in order to assert that modules are resolved in the correct sequence. However, from the perspective of the ECMA-262 specification, the ordering of *export* (e.g. binding) resolution is not observable. This is due to restrictions on the grammar, where each export is independent. When *export* resolution fails, it does so with instances of SyntaxError alone, precluding the above strategy. So while ModuleDeclarationInstantiation resolves the exports of the module's dependencies in the following order: 1. "Indirect" exports, e.g. - `export { x } from './y.js';` - `export { x as z } from './y.js';` - `import { x } from './y.js'; export { x };` 2. "Star" imports - `import * as ns from './y.js';` 3. "Named" (my word) imports - `import x from './y.js';` - `import { x } from './y.js';` - `import { x as z } from './y.js';` Intentional failures cannot be used to discern resolution ordering.
2016-03-29 17:50:15 +02:00
assert('namedOther' in named);
assert.sameValue(
'default' in named, false, 'default specified via identifier'
);
assert('productionOther' in production);
assert.sameValue(
'default' in production, false, 'default specified via dedicated production'
);