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.
There were three things wrong with the 'and', 'or', and 'nullish' tests
that I added as part of #2940:
1. They were in the wrong folder (should be
expressions/logical-assignment, not expressions/compound-assignment)
2. The tests for ||= and ??= on readonly accessor properties were
incorrect. These assignments would short-circuit if the getter
returned 1 as it previously did, so PutValue would not throw.
3. The tests for ||= and ??= on private methods were invalid, as a
method always evaluates to true in a boolean context, and is not
nullish, so these would always short-circuit.
I've removed the invalid private method cases, fixed the readonly
accessor cases, and added new templates to test the short-circuit
behaviour as well as the non-short-circuit behaviour.
Closes: #3413
This tests compound assignment, with each compound assignment operator,
to each kind of private reference (private field, private accessor
property with getter and setter, private accessor property with only
getter, and private method). The latter two cannot be assigned to and
therefore throw.
Closes: #2940
The phase field must precede the type field for negative tests
to have a consistent style and be able to parse easier.
Related to the goal of https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
The `arrayContains` function has a number of deficiencies which make it
inappropriate for Test262:
- It apparently isn't very useful: despite being available for over 7
years, fewer than ten tests use it
- It's misleading: its documentation reads, "Verify that a subArray is
contained within an array." In reality, it only verifies that all the
elements of one array are present in another--order does not matter.
- It's not ergonomic for test authors: it has been misused to create
tests that were prone to false positives [1]
- It's not ergonomic for implementers: ostensibly designed for use with
`assert`, the failure messages produced by tests that use it do not
necessarily have very much context
All code in the "harness" directory adds to the total amount of
project-specific information which contributors are expected to to
learn. In light of the above deficiencies, the burden of this particular
harness file is unjustified.
Remove the harness file and its associated tests. Update the tests which
depend on it to express their expectations using alternate methods, and
strengthen the tests to assert element order wherever appropriate.
[1] https://github.com/tc39/test262/pull/3289
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.
Attempting to freeze the module namespace exotic object should not affect the `writable`-ity of the properties as that exercises the same `DefineOwnProperty` operation according to [`SetIntegrityLevel`](https://tc39.es/ecma262/#sec-setintegritylevel).
@erights discovered a [bug in v8](https://bugs.chromium.org/p/v8/issues/detail?id=12240) where, while the `Object.freeze` operation throws, it actually makes exported properties non-writable one by one.
At the request of @syg, I'm contributing a test against this behavior. The bug in v8 actually leads to a breakage of the objects invariants, however I'm not testing for that here as the root cause is the illegal freezing of the export.
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).
Prior to this commit, the modified test included two different
expressions in positions that were meant to describe the same
expression. This meant that the value of the intended expression was
only partially verified.
Correct the test to fully verify the value of the expression.
Prior to this patch, two distinct failure cases would produce the same
generic error message. Refactor the test logic to report the specific
condition which trigger failure.
The following proposed change modifies the semantics this test was
originally written to verify:
Normative: Allow null or undefined in Reference Records
https://github.com/tc39/ecma262/pull/2267
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
These tests support the following normative change
"Normative: Allow null or undefined in Reference Records"
https://github.com/tc39/ecma262/pull/2267
The tests concerning the `delete` operator increase coverage to verify
behavior which, though related, is not altered by the normative change.
These tests are intended to guard against regressions as engines
implement the new semantics.
Additionally, update test metadata and introduce two new tests to
complete coverage.
Reference: "Normative: Make B.1.{1,2} normative"
https://github.com/tc39/ecma262/pull/1867
André Bargull
Nicolò Ribaudo
Nicolò Ribaudo
Michael Dyck
José Julián Espina
Veera
Huáng Jùnliàng
Cam Tenny
Philip Chimento
Rick Waldron
Gokhan Kurt
Mathias Bynens
Kevin Gibbons
legendecas
Youssef Soliman
Mike Pennisi
Dmitriy Kubyshkin
Keith Miller
Richard Gibson
Philip Chimento
Csaba Osztrogonác
Daniel Nalborczyk
Rick Waldron
Mathieu Hofman
Mickey Rose
devsnek
Timothy Gu
Dan Clark