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 CL adds the requirement of having disposed stack before
calling DisposeResources on the DisposableStack.
Bug: 42203506
Change-Id: I515a5f23e609fdd9448cebc4cd71b0176c86cf99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6298949
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98902}
This CL fixes the async disposal from sync methods that return
a promise. The result of calling `symbol.dispose` should
not be used to resolve the outer promise.
Bug: 42203814
Change-Id: I4c4573035b74b06ad78e2810e3f132301954c048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6291492
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98898}
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 CL adds one suspend point in any scope that has at least one
`await using` in it.
Bug: 396661138
Change-Id: I144a0ca49395b34309e7e35f070c98cc145af34b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6279751
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98811}
It is an early error if the LHS of:
- ForOfStatement
- UpdateExpression
- AssignmentExpression
- DestructuringAssignmentTarget
is not simple (i.e. not a function call).
These tests are all based on the existing dynamic import syntax tests, just updated to use the new syntax.
This PR does not contain any manually written tests -- they are all generated.
The "islamic" calendar id refers to the observational Islamic calendar
and different implementation may use different algorithms to approximate
when the moon's crescent can be observed. Change the test data to allow
the approximations used in ICU4X in addition to the ones used in ICU4C.
ayuan0828
Tim Chevalier
Philip Chimento
Ms2ger
Rezvan Mahdavi Hezaveh
Luca Casonato
Seokho Song
Sosuke Suzuki
Nicolò Ribaudo
Linus Groh
Rezvan Mahdavi Hezaveh
Chengzhong Wu
André Bargull
lionel-rowe
Frank Yung-Fong Tang
Brage Hogstad
yossydev
Ron Buckton
Kevin Gibbons
Boshen
Justin Dorfman