Because these files contain syntax errors, the code they contain is not
intended to be executed, and the runtime semantics are therefore
irrelevant. Simplify the files by removing the unnecessary code.
Early errors may result from parsing the source text of a test file, but
they may also result from parsing some other source text as referenced
through the ES2015 module syntax. The latter form of early error is not
necessarily detectable by ECMAScript parsers, however. Because of this,
the label "early" is not sufficiently precise for all Test262 consumers
to correctly interpret all tests.
Update the "phase" name of "early" to "parse" for all those negative
tests that describe errors resulting from parsing of the file's source
text directly. A forthcoming commit will update the remaining tests to
use a "phase" name that is more specific to module resolution.
* Accessing `ta[0]` throws a TypeError.
* Fix array indices starting at 0 and property references
* Fix classfields templates for properly checking static propnames.
* Generate tests
* `assert.equal` is not defined
* Add missing includes
* Generate tests
* typo s/Avalue/42/
* fix whitespace
* Add missing var for strict mode
* Expand generated class fields tests for forbidden computed property name values
Ref https://github.com/tc39/test262/pull/1339#issuecomment-342830243
* derived classes have access to private names in base classes, if private names are in scope
Tests doesn't use async functionality and don't call $DONE, so remove
"async" flag:
- src/params/error/async-gen-named-func-expr.template
- test/language/expressions/async-generator/params-named-dflt-abrupt.js
- test/language/expressions/async-generator/params-named-dflt-ref-later.js
- test/language/expressions/async-generator/params-named-dflt-ref-self.js
Intl.PluralRules.prototype is no longer a Intl.Prototype instance:
- test/intl402/PluralRules/prototype/prototype.js
Intl.PluralRules throws an error when called as a function:
- test/intl402/PluralRules/undefined-newtarget-throws.js
Module namespace objects call OrdinaryDelete for symbol properties:
- test/language/module-code/namespace/internals/delete-non-exported.js
Async generators no longer retrieves "done" property twice:
- src/async-generators/yield-star-async-next.case
- src/async-generators/yield-star-async-return.case
- src/async-generators/yield-star-async-throw.case
Minor units of CLF is 4, so we need to test with maximumFractionDigits=3
to get an error:
- test/intl402/NumberFormat/dft-currency-mnfd-range-check-mxfd.js
DateTimeFormat.prototype.formatToParts length property was changed from
0 to 1:
- test/intl402/DateTimeFormat/prototype/formatToParts/length.js
minimumSignificantDigits and maximumSignificantDigits properties are
only retrieved once:
- test/intl402/NumberFormat/11.1.1_32.js
test/annexB/built-ins/Date/prototype/setYear/time-clip.js
test/built-ins/Date/prototype/setFullYear/new-value-time-clip.js
test/built-ins/Date/prototype/setMonth/new-value-time-clip.js
- Don't try to test time-clip at the end points, because this is near
impossible to get right (needs to consider time zone offset, dst, local
mean time because of Africa/Monrovia, etc.).
test/built-ins/DataView/prototype/setFloat64/detached-buffer-after-toindex-byteoffset.js
test/built-ins/DataView/prototype/setInt16/detached-buffer-after-toindex-byteoffset.js
- Wasn't update to expect RangeError
test/built-ins/Function/internals/Construct/derived-this-uninitialized-realm.js
- Change ClassDeclaration -> ClassExpression to get completion value
test/built-ins/Function/prototype/toString/AsyncFunction.js
- Add missing \n in expected string
- Also fixed in gh-847
test/built-ins/global/global-object.js
- Add 'var' to make test pass in strict-mode
test/language/block-scope/syntax/redeclaration-in-block/attempt-to-redeclare-function-declaration-with-function-declaration.js
- This is allowed in sloppy mode when Annex B is implemented
test/language/expressions/async-generators/expression-yield-as-statement.js
- Fix calls to then()
test/language/module-code/namespace/internals/own-property-keys-binding-types.js
test/language/module-code/namespace/internals/own-property-keys-sort.js
- Tests weren't updated after removal of @@iterator from module
namespace objects
test/language/module-code/namespace/internals/set-prototype-of-null.js
- Fix syntax error
test/language/statements/async-function/early-errors-no-async-generator.js
- No longer valid now that async iteration proposal is at stage 3
Authored via the following command:
$ find test -type f -print0 | \
xargs -0 sed \
-i 's/^\(\s*\)negative:\s*SyntaxError\s*$/\1negative:\n\1 phase: early\n\1 type: SyntaxError/g'
The expected errors in these tests cannot be asserted with the
`assert.throws` helper function for various reasons. Re-format their
meta-data according to the latest design in order to more precisely
describe test expectations.
The file previously named `values-binding-types_.js` is not intended to
be interpreted as a test. Therefor (in accordance with the project's
`INTERPETING.md` file), its name should include `_FIXTURE` as a suffix.
Files whose name ends in `_.js` are not themselves valid Test262 tests
and should not be interpreted as such by test runners.
---
The tests for the GetBindingValue method of the module Environment
Record are very minimal. This is because GetBindingValue is necessary to
assert any aspect of binding creation/initialization/mutation. In this
way, GetBindingValue is being implicitly tested by every test that
references a binding value.
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.
Assert that ImportDeclaration and ExportDeclaration match only the
ModuleItem symbol.
According to the definition of HostResolveImportedModule, it is
acceptable for an implementation to throw a SyntaxError in the event
that a requested module can neither be found nor created:
> If a Module Record corresponding to the pair referencingModule,
> specifier does not exist or cannot be created, an exception must be
> thrown.
In order to reliably detect a SyntaxError in response to the correct
interpretation of the grammar (and not a SyntaxError from an *incorrect*
interpretation of the grammar followed by a failure to resolve the
requested module), the ModuleSpecifier of ExportDeclarations should
describe a valid resource.
Mike Pennisi
Yusuke Suzuki
André Bargull
Rick Waldron
Leo Balter
Valerie R Young
Georg Neis
Kevin Gibbons
Adam Klein
Gorkem Yakin