Adds a test similar to the one in #3697, but in the main tree.
The six code points in this test have an "F" for full case mapping in
CaseFolding.txt, and so they should not be considered in the
Canonicalize operation.
Current versions of SpiderMonkey and V8 fail this test, others pass.
These tests should cover the full functionality of the .groups object (and
the .indices.groups object, in the case of the /d flag) for RegExp.p.exec
and String.p.match:
- Matched DNCG has a result
- Unmatched DNCG is present and undefined
- DNCG matched in previous iteration but not in current iteration is
treated as unmatched
- Iteration order of properties corresponds with source order
See: #3704
Each named capturing group should count as its own parenthesized capturing
group, even if it has the same name as another group. So, some of these
expectations were missing `undefined` array elements for the variant of
the `x` capturing group that didn't match.
In the other expectations, we forgot to take into account that the
backreference is not inside a capturing group, so the group match should
not have doubled letters in it.
Parse-time syntax for RegExp literals is already tested. These two files
test runtime RegExp compilation, with respect to duplicate named capture
groups.
See: #3704
I discovered these tests had omitted some arguments to the PlainDateTime
constructor, leaving the calendar in the wrong position.
The tests were technically not incorrect, since the operation
ToIntegerThrowOnInfinity on the string "gregory" gives 0. But they could
spuriously pass if the implementation didn't do argument conversion
correctly, failed to throw on eraYear being ±Infinity, but subsequently
threw RangeError anyway because the calendars of the arguments didn't
match.
This tests the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to the
Temporal.Calendar.prototype.mergeFields method.
Due to the use of the pre-existing spec operation CopyDataProperties, now
symbol keys are merged into the return value, and the order of observable
property operations has changed from a batch of [[GetOwnProperty]]
followed by a batch of [[Get]], to a series of interleaved
[[GetOwnProperty]]/[[Get]] pairs.
This tests some of the normative changes in
https://github.com/tc39/proposal-temporal/pull/2245, which achieved
consensus in the July 2022 TC39 meeting, specifically as they apply to
places where the MergeLargestUnitOperation was called.
Due to the use of the pre-existing spec operation CopyDataProperties, the
order of observable property operations has changed from a batch of
[[GetOwnProperty]] followed by a batch of [[Get]], to a series of
interleaved [[GetOwnProperty]]/[[Get]] pairs. This previously wasn't
tested because TemporalHelpers.propertyBagObserver didn't track
[[GetOwnProperty]] operations, but now it does.
Using assert.deepEqual was faulty here, since deepEqual doesn't take
symbol keys into account. This test wasn't actually testing that the
symbol keys were absent, and in fact passes if they are present.
(Rather than fixing deepEqual, since we hope to deprecate it as per
https://github.com/tc39/test262/issues/3476, add a custom assert function
in the test.)
Normally, a plain object passed into an API that takes a Temporal.TimeZone
has its 'timeZone' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.TimeZone
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalTimeZone, with a "poisoned" timeZone object which has the
correct internal slots but a 'timeZone' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
Normally, a plain object passed into an API that takes a Temporal.Calendar
has its 'calendar' property checked (observably) with a Has operation
followed by a Get operation if the property is present. In the normative
change https://github.com/tc39/proposal-temporal/pull/2392 which reached
consensus at the September 2022 TC39 meeting, this was changed so that
this check is skipped for objects which have the Temporal.Calendar
internal slots.
This adds tests to all entry points that pass a user-supplied object to
ToTemporalCalendar, with a "poisoned" calendar object which has the
correct internal slots but a 'calendar' accessor property whose getter
throws. A correct implementation should not cause this getter to throw.
In these tests, we should make a distinction in the name for clarity. It's
testing a time zone passed as a property in a property bag (either as an
argument, or as a relativeTo option), so name it accordingly as we do with
other tests in the same folder.
This looks like a bug: resolveAsyncGC() is supposed to succeed if the
thrown value is asyncGC.notCollected, but instead it would call $DONE()
twice. An added "return" prevents that.
It's possible for an async test to throw a Symbol (harness/async-gc.js
does this.) The Symbol ends up getting passed to $DONE in a
.then($DONE, $DONE) call. Previously, $DONE would then throw an exception
due to not being able to convert the Symbol to a string.
This adds tests to WeakMap, WeakSet, WeakRef, and FinalizationRegistry for
Symbols as weakly-held values. Regular symbols and well-known symbols are
both tested. These tests correspond to existing tests for Objects as
weakly-held values, but are put in separate files so that they can be
filtered out with the "symbols-as-weakmap-keys" feature flag.
Registered symbols are not allowed; this is already tested in the "cannot-
be-held-weakly" tests.
See: #2850
There are many existing tests for WeakMap, WeakSet, WeakRef, and
FinalizationRegistry using Objects as weak values. For symbols-as-weakmap-
keys, we'll want to write tests that parallel these for Symbol keys.
Change the descriptions and filenames of these tests to describe their new
scope of only Object weak values.
Update the front matter of these tests while we're at it, to reflect the
changes to the spec text that the symbols-as-weakmap-keys brings in. (In
some cases, remove irrelevant bits of the front matter.)
See: #2850
WeakMap, WeakSet, WeakRef, and FinalizationRegistry all had tests
verifying what would happen if they were called with a value that wasn't
allowed as a weak value: before this proposal, that was a non-Object.
Now, allowed weak values are Objects, well-known Symbols, and unregistered
Symbols. That leaves registered Symbols that are still not allowed as weak
values.
This commit updates those tests to use a registered Symbol instead of an
unregistered Symbol; they should still pass, regardless of whether the
implementation has implemented symbols-as-weakmap-keys yet.
The tests are renamed as appropriate.
Also updates the frontmatter to the most current spec text, including the
CanBeHeldWeakly abstract operation.
See: #2850
This test is duplicated by WeakSet/prototype/add/value-not-object-throw.js
Originally taken from Rick's draft commit for symbols-as-weakmap-keys
tests.
See https://github.com/tc39/proposal-temporal/pull/2316 which eliminated
an observable call to Array.prototype[Symbol.iterator]() in the case where
a calendar's 'fields' property was undefined.
The best way I've thought of to test this is to monkeypatch the
Array.prototype[Symbol.iterator]() method to make it throw. In some cases,
where we are actually expected to iterate the return value from a
Temporal.TimeZone's getPossibleInstantsFor() method, we have to provide a
custom method for that as well, that returns a non-Array iterable so we
don't call the patched Array.prototype[Symbol.iterator]().
This normative change reached consensus at the July 2022 TC39 plenary
meeting.
The programmer always gets the last word over how the string is
interpreted, since otherwise it's not possible to make any guarantees
about the offset option. (This is the "out-of-band" mechanism mentioned in
the IETF draft.) Add a test for this.
Based on the improvements just made to the calendarName option, improve
the tests for the timeZoneName option of ZonedDateTime.prototype.toString
as well.
Since we are going to be adding a new test for calendarName: "critical",
take the existing tests for various values of the calendarName option, and
regularize them. Previously, depending on which type's toString() method
was under test, the tests had various degrees of thoroughness, and some
were only present in staging.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with more than one time zone annotation. These
are not syntactically correct according to the grammar and should be
rejected.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with unrecognized annotations, (i.e., neither
time zone nor calendar), in various combinations with recognized
annotations.
See https://github.com/tc39/proposal-temporal/pull/2397
Adds tests for ISO strings with calendar annotations, with and without the
critical flag, and also a check that the second calendar annotation is
disregarded, as per the IETF draft.
Ms2ger
Philip Chimento
Mathias Bynens
Rick Waldron
Timothy Flynn
Shu-yu Guo
Richard Gibson
Linus Groh
Nicolò Ribaudo
Gokhan Kurt
Rick Waldron