* Add "feature" for "Resizable ArrayBuffer" proposal
* Resizable ArrayBuffer: DataView methods
The files in this patch are highly similar. Only the test for
`DataView.prototype.getBigInt64` and `DataView.prototype.setBigInt64`
were written manually. The others were generated from those files via
the following script:
#!/bin/bash
set -eu
names='
BigUint64
Float32
Float64
Int16
Int32
Int8
Uint16
Uint32
Uint8
'
for name in ${names}; do
lower=$(echo ${name} | tr '[:upper:]' '[:lower:]')
if [ ${name} == 'BigUint64' ]; then
replace_bigints=''
else
replace_bigints='-e s/\b\([0-9]\+\)n\b/\1/g'
fi
sed \
-e "s/getbigint64/get${lower}/g" \
-e "s/getBigInt64/get${name}/g" \
${replace_bigints} \
./test/built-ins/DataView/prototype/getBigInt64/resizable-buffer.js \
> ./test/built-ins/DataView/prototype/get${name}/resizable-buffer.js
sed \
-e "s/setbigint64/set${lower}/g" \
-e "s/setBigInt64/set${name}/g" \
${replace_bigints} \
./test/built-ins/DataView/prototype/setBigInt64/resizable-buffer.js \
> ./test/built-ins/DataView/prototype/set${name}/resizable-buffer.js
done
* Fix test for only {localeMatcher: "lookup"}
The expectation that "sr-Thai-RS" would be returned is only true with the
9.2.2 BestAvailableLocale ( availableLocales, locale )
https://tc39.es/ecma402/#sec-bestavailablelocale
algorithm used by 9.2.3 LookupMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-lookupmatcher
The default for localeMatcher is "best fit" but not "lookup" for all Intl objects.
And for 9.2.4 BestFitMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-bestfitmatcher
It may not match "sr-Thai-RS" for "sr" and return ["de", "zh-CN"] instead. Therefore, we need to change this test to only test on {localeMatcher: "lookup"}
* Add option to getLocaleSupportInfo
Needed to test different localeMatcher
* only test for "lookup" localeMatcher
* Get the info based on the localeMatcher
* pass in localeMatcher to getLocaleSupportInfo
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.
* Add tests for Object.hasOwn
* Update test/built-ins/Object/hasOwn/length.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Update test/built-ins/Object/hasOwn/name.js
Co-authored-by: Jordan Harband <ljharb@gmail.com>
* Fixup comments for Object.hasOwn
* Add Object.hasOwn descriptor test
* use assert.sameValue with true instead of assert()
* remove extra semicolons
* Remove old $ERROR style tests from hasown
* Fix thrown error type in hasown tests
* Fix incorrect test cases
Co-authored-by: Jordan Harband <ljharb@gmail.com>
This change is in service of forthcoming tests for the "JSON modules"
language proposal [1]. Verifying the semantics of that proposal requires
modules whose source text is not valid ECMAScript; this change updates
the guidelines for contributing and interpreting tests so that such test
material can be handled consistently.
Differentiating JSON files with a distinct file name suffice will assist
consumers which require special handling of such files (e.g. web
browsers).
Change the pattern used to designate "fixture" files so that it may be
applied to files used for JSON modules.
Increment the project version number to alert consumers of this change
in interpreting instructions.
[1] https://github.com/tc39/proposal-json-modules
Prior to this patch, the CircleCI continuous integration environment was
configured to report test failures in a negative light, displaying red
cross-marks and reporting that "some checks were not successful" in
commits and GitHub Pull Requests which included them.
The passing/failing status of tests does not influence their
desirability for Test262. (In practice, engines very commonly fail
newly-contributed tests.)
Although these conflicting interpretations does not technically
interfere with the maintainers' ability to merge new contributions, it
does create confusion for many contributors who interpreted the UI as a
rejection of their work.
In addition, this behavior made it impossible to distinguish between the
benign test failures and disruptive infrastructural problems (e.g. the
crashing of engines).
Reconfigure the continuous integration environment to accept passing and
failing tests equally, and to only report a problem when the Test262
project's testing infrastructure behaves unexpectedly.
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
* Add basic tests for weekInfo
* Add basic tests for textInfo
* Add basic tests for timeZones
* Add basic tests for numberingSystems
* Add basic tests for hourCycles
* Add basic tests for collations
* Add basic tests for calendars
* Add feature for Intl.Locale-info
* add validation to branding tests for locale-info
Add additional assertion to branding tests for proposal-intl-locale-info
to make sure they don't pass spuriously when the proposal is not
implemented.
This metadata was not in use when it was first documented in 2014 [1],
and it has not been referenced since that time. It has never been
referenced by `INTERPRETING.md`.
[1] 5b8879b951
Minimize the code provided to the `assert.throws` utility in order to
reduce the possibility of false positives and to improve failure
messages in non-conforming runtimes.