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: Modules have distinct environment records
|
|
|
|
esid: sec-moduledeclarationinstantiation
|
|
|
|
info: |
|
|
|
|
[...]
|
|
|
|
6. Let env be NewModuleEnvironment(realm.[[GlobalEnv]]).
|
|
|
|
7. Set module.[[Environment]] to env.
|
|
|
|
[...]
|
|
|
|
|
|
|
|
8.1.2.6 NewModuleEnvironment (E)
|
|
|
|
|
|
|
|
1. Let env be a new Lexical Environment.
|
|
|
|
[...]
|
|
|
|
flags: [module]
|
2017-10-26 23:05:18 +02:00
|
|
|
features: [generators]
|
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
|
|
|
---*/
|
|
|
|
|
2016-04-22 22:21:55 +02:00
|
|
|
import './instn-uniq-env-rec-other_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
|
|
|
var first = 1;
|
|
|
|
let second = 2;
|
|
|
|
const third = 3;
|
|
|
|
class fourth {}
|
|
|
|
function fifth() { return 'fifth'; }
|
|
|
|
function* sixth() { return 'sixth'; }
|
|
|
|
|
|
|
|
assert.sameValue(first, 1);
|
|
|
|
assert.sameValue(second, 2);
|
|
|
|
assert.sameValue(third, 3);
|
|
|
|
assert.sameValue(typeof fourth, 'function', 'class declaration');
|
|
|
|
assert.sameValue(typeof fifth, 'function', 'function declaration');
|
|
|
|
assert.sameValue(fifth(), 'fifth');
|
|
|
|
assert.sameValue(typeof sixth, 'function', 'generator function declaration');
|
|
|
|
assert.sameValue(sixth().next().value, 'sixth');
|
|
|
|
|
|
|
|
// Two separate mechanisms are required to ensure that no binding has been
|
|
|
|
// created for a given identifier. A "bare" reference should produce a
|
|
|
|
// ReferenceError for non-existent bindings and uninitialized bindings. A
|
|
|
|
// reference through the `typeof` operator should succeed for non-existent
|
|
|
|
// bindings and initialized bindings. Only non-existent bindings satisfy both
|
|
|
|
// tests.
|
|
|
|
typeof seventh;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
seventh;
|
|
|
|
});
|
|
|
|
|
|
|
|
typeof eight;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
eighth;
|
|
|
|
});
|
|
|
|
|
|
|
|
typeof ninth;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
ninth;
|
|
|
|
});
|
|
|
|
|
|
|
|
typeof tenth;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
tenth;
|
|
|
|
});
|
|
|
|
|
|
|
|
typeof eleventh;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
eleventh;
|
|
|
|
});
|
|
|
|
|
|
|
|
typeof twelfth;
|
|
|
|
assert.throws(ReferenceError, function() {
|
|
|
|
twelfth;
|
|
|
|
});
|