mirror of
				https://github.com/tc39/test262.git
				synced 2025-10-25 17:53:53 +02:00 
			
		
		
		
	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.
		
	
			
		
			
				
	
	
		
			58 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			JavaScript
		
	
	
	
	
	
			
		
		
	
	
			58 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			JavaScript
		
	
	
	
	
	
| // Copyright (C) 2016 the V8 project authors. All rights reserved.
 | |
| // This code is governed by the BSD license found in the LICENSE file.
 | |
| /*---
 | |
| description: Imported binding reflects state of exported function binding
 | |
| 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
 | |
|            [...]
 | |
|         c. Else,
 | |
|            i. Let resolution be ?
 | |
|               importedModule.ResolveExport(in.[[ImportName]], « », « »).
 | |
|            ii. If resolution is null or resolution is "ambiguous", throw a
 | |
|                SyntaxError exception.
 | |
|            iii. Call envRec.CreateImportBinding(in.[[LocalName]],
 | |
|                 resolution.[[Module]], resolution.[[BindingName]]).
 | |
|     [...]
 | |
|     16. Let lexDeclarations be the LexicallyScopedDeclarations of code.
 | |
|     17. For each element d in lexDeclarations do
 | |
|         a. For each element dn of the BoundNames of d do
 | |
|            i, If IsConstantDeclaration of d is true, then
 | |
|               1. Perform ! envRec.CreateImmutableBinding(dn, true).
 | |
|            ii. Else,
 | |
|                1. Perform ! envRec.CreateMutableBinding(dn, false).
 | |
|            iii. If d is a GeneratorDeclaration production or a
 | |
|                 FunctionDeclaration production, then
 | |
|                 1. Let fo be the result of performing InstantiateFunctionObject
 | |
|                    for d with argument env.
 | |
|                 2. Call envRec.InitializeBinding(dn, fo).
 | |
|     [...]
 | |
| 
 | |
|     8.1.1.5.5 CreateImportBinding
 | |
| 
 | |
|     [...]
 | |
|     5. Create an immutable indirect binding in envRec for N that references M
 | |
|        and N2 as its target binding and record that the binding is initialized.
 | |
|     6. Return NormalCompletion(empty).
 | |
| flags: [module]
 | |
| ---*/
 | |
| 
 | |
| assert.sameValue(
 | |
|   f2(),
 | |
|   23,
 | |
|   'binding is initialized to function value prior to module evaluation'
 | |
| );
 | |
| 
 | |
| assert.throws(TypeError, function() {
 | |
|   f2 = null;
 | |
| }, 'binding rejects assignment');
 | |
| 
 | |
| assert.sameValue(f2(), 23, 'binding value is immutable');
 | |
| 
 | |
| import { f as f2 } from './instn-named-bndng-fun.js';
 | |
| export function f() { return 23; }
 |