test262/test/language/module-code/instn-iee-err-dflt-thru-sta...

// Copyright (C) 2016 the V8 project authors. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.

var x;
export { x as default };
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.`

			`var x;`
			`export { x as default };`