For the statement level test, the inner class name is not initialized
at the time the decorators evaluate, resulting in a ReferenceError
that the declaration can not be accessed prior to initialization.
Similar, non-decorator code, like:
class C {
static dec() {}
static {
this.x = C.dec();
class C {}
}
}
also results in a ReferenceError.
For the expression level test, the var C is undefined at the time the
decorators are evaluated, resulting in TypeError while trying to access
a member of undefined.
Similar, non-decorator code, like:
var C = class {
static f() {};
static {
this.x = C.f();
}
}
also results in a TypeError.
While we're at it, use assert() instead of assert.sameValue() for brevity,
if we are not specifically testing that the return value of hasOwnProperty
is the value true or false; and add more informative assertion messages to
help with debugging.
In some cases, the Object.hasOwnProperty.call could be replaced with
verifyProperty(), if the property descriptor was also being verified at
the same time.
This fixes some tests that were faulty to begin with: a common mistake was
Object.hasOwnProperty(obj, prop) which is probably going to return false
when that's not what you want.
The only instances left of `Object.hasOwnProperty` are one regression test
in implementation-contributed which I can't tell if it was intentionally
needed to trigger the regression, and a few instances of
`Object.hasOwnProperty('prototype')` which would defeat the purpose to
convert into `Object.prototype.hasOwnProperty.call(Object, 'prototype')`
form.
Closes: #3524
Prior to this commit, two tests for specific early errors also included
syntactically invalid `const` declarations. Implementations which
produced the expected syntax error due to these invalid declarations
would pass the tests regardless of whether they produced the early
errors that the tests were written to verify.
Correct the `const` declarations so that the tests verify the parsing
rule that they were designed to verify.
The test as originally specified fails in all compatible parsers, but for the wrong reason. Below is an excerpt from V8, but all parser I tested behave the same:
```js
for (const x; false; ) {
^
SyntaxError: Missing initializer in const declaration
```
After the change the error is the assumed:
```js
var x;
^
SyntaxError: Identifier 'x' has already been declared
```
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
Some tests which include function declarations designed to verify
behavior do not reference those functions. Insert the references
necessary for those functions to serve their intended purpose.
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
Prior to this commit, the modified tests used the strict equality
operator to compare computed values with negative zero. Due to the
semantics of that operator, these tests would spuriously pass if the
value under test was in fact positive zero.
Update the tests to be more precise by instead asserting equality with
the `assert.sameValue` utility method (since that method correctly
distinguishes between negative zero and positive zero).
Since https://github.com/tc39/ecma262/pull/1490, the "length" and "name"
properties of a class are defined before any static methods. This is
tested by #2057, in test/language/computed-property-names of all places.
At the same time, static methods with "name" as the name would overwrite
the original property, but retain the original property enumeration
order. This was not previously tested. In fact, the overwriting behavior
was not tested at all for the "length" property.
This commit mends both holes in test coverage.
* Add tests for "Class Static Init. Blocks" proposal
This proposal is currently at "stage 3" in TC39's standardization
process.
* fixup! Add tests for "Class Static Init. Blocks" proposal
* Correct identifier reference
* Update tests for grammar
* Update tests for identifiers
* Add tests for scope derivation
Several tests for getters and setters claim to check for an early
SyntaxError regarding mixing static and non-static propeties with the
same name. However, the tests trigger another issue: the getters have no
method body; they're missing curlies.
Fix the tests to test only the intended SyntaxError, not unrelated
SyntaxError-s.
Kevin Gibbons
Daniel Minor
André Bargull
Huáng Jùnliàng
José Julián Espina
Cam Tenny
Philip Chimento
legendecas
Youssef Soliman
Mike Pennisi
Dmitriy Kubyshkin
Keith Miller
rwaldron
Rick Waldron
Timothy Gu
Stuart Cook
strager
Gus Caplan
jmdyck
Caio Lima