The objects it provides are also available in another harness file,
wellKnownIntrinsicObjects.js. There's no point in duplicating that in the
harness. Rewrite each test that used hidden-constructors.js to use
getWellKnownIntrinsicObject instead.
wellKnownIntrinsicObjects.js now exposes a getWellKnownIntrinsicObject()
function which returns the object corresponding to a key like %Array%. If
the object is not provided by the implementation, or not accessible, it
throws a Test262Error. This is so that tests depending on that intrinsic
object can easily fail.
Looks like this list hasn't been updated in a while. Add
%AsyncGeneratorPrototype%, %GeneratorPrototype%, %Iterator%,
%IteratorHelperPrototype%, and %WrapForValidIteratorPrototype%.
%IteratorPrototype% is no longer a well-known intrinsic; I guess it was
removed because ever since iterator helpers it's accessible as
%Iterator.prototype%.
%Iterator% is available as the global property Iterator, but include a
fallback for implementations that haven't yet implemented iterator
helpers.
As far as I can tell these are wrong, giving %GeneratorFunction.prototype%
and %AsyncGeneratorFunction.prototype% instead. These new expressions are
how MDN claims you can get the intrinsics.
As far as I know, %AsyncFromSyncIteratorPrototype% and
%ForInIteratorPrototype% are not (and not intended to be) accessible to
ECMAScript user code, so they are impossible to test directly. Add a
clarifying comment, and make the source expression consistent ('' vs.
'undefined').
This adds coverage for the normative change in
https://github.com/tc39/proposal-temporal/pull/3054, which specifies that
implementations must throw on out-of-range dates in RFC 9557 strings for
non-ISO calendars.
This is now unused, and there is no way to implement it without using the
cleanupSome proposal (see previous commit) which has been withdrawn.
Closes: #3920
* Fix syntax error from #4164
Function statements require a name.
See #4166
* Apply suggestions from code review
Co-authored-by: Jordan Harband <ljharb@gmail.com>
---------
Co-authored-by: Jordan Harband <ljharb@gmail.com>
Temporal doesn't specify concrete era names, so tests shouldn't assert
for example that the era code of the current Gregorian era is `"ce"`. We
still want to validate the era names somehow however, so allow alternative
era names using the era codes from the "Intl era and monthCode" proposal.
Previously getISOFields() was used to get the exact value of the
[[Calendar]] and [[TimeZone]] internal slots, as well as to get the
reference ISO year for PlainMonthDay and reference ISO day for
PlainYearMonth.
Use calendarId and timeZoneId for the former and toString() for the
latter.
These are no longer possible without custom objects. Also add an exception
for calendar and timeZone properties in property bag observers so they are
not treated as objects.
Many tests tested some functionality while asserting that there were no
calls of calendar or time zone methods. We can continue testing the
functionality, but there are no more methods to call, so we can delete
those parts of the tests.
It's no longer possible to fake built-in time zones using custom objects.
So testing DST shifts will have to use real built-in time zones. Replace
TemporalHelpers.springForwardFallBackTimeZone with America/Vancouver (it
was modelled on the DST transitions in 2000) and
TemporalHelpers.crossDateLineTimeZone with Pacific/Apia (it was modelled
on the 2011 switch to the other side of the international date line.)
These tests have to move to the intl402/ folder since non-Intl-aware
implementations are allowed (but not required) to support any built-in
time zones other than UTC.
In many cases we created a TimeZone or Calendar instance from a built-in
time zone or calendar. These tests can be trivially adapted to just use
the string ID.
There is no such hidden constructor, it's the same as the hidden
AsyncFunction constructor. In other words:
```js
Object.getPrototypeOf(async () => {}).constructor ===
Object.getPrototypeOf(async function () {}).constructor
```
Also add a test to ensure that %AsyncFunction.prototype% is indeed the
prototype of an async arrow function.
Closes#4044.
Philip Chimento
Ms2ger
André Bargull
Richard Gibson
Peter Hoddie
Linus Groh
Marko Lahma
Ioanna M Dimitriou H
José Julián Espina
Paul Bakker
Paul Bakker