This check skips inserting a breakpoint into the BreakPointInfo if
it has already been inserted before.
Change-Id: Ic773fe1d6b2351bf6069fa0ff002737bd0b03293
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253851
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68447}
This implements I32x4DotI16x8S for ia32.
Also fixes instruction-selector for SIMD ops, they should all set operand1 to be a register, since we do not have memory alignment yet.
Bug: v8:10583
Change-Id: Id273816efd5eea128580f3f7bde533a8e1b2435d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2231031
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68444}
Refer to "Advanced SIMD two registers misc", ARM DDI 0487F.b F4-4228.
Also moved the method down to the section with all the NEON
instructions, matching where the declaration in assembler-arm.h is.
Bug: v8:10553
Change-Id: I450edbfc3eafead4aad419299c93e43bd9d83133
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252764
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68442}
Replace by "consistency check", or "validity check", or more specific
wording as appropriate.
R=ecmziegler@chromium.org
Bug: v8:10619
Change-Id: Ifd7852d8f703d5b784d53671b82d65db15722ede
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253855
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68440}
Formerly, we zapped a transition array when we replaced it with a
larger one, but this is no longer necessary. Leaving those arrays in
peace makes life easier for concurrent (racy) access from a background
compilation thread.
Design doc with more info about racy access to transition arrays
between the main JavaScript thread and a background compilation thread
here:
https://docs.google.com/document/d/1ax2qyENdr50Qu9yur1qNu6_zRK0m6K2l7BLM_QDBFJM/edit?usp=sharing
Change-Id: I4c2757945266d43d82ec157e0ff2b9208a8e4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253840
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68437}
This CL migrates the bots v8_mac64_gc_stress_dbg
and v8_mac64_asan_rel to the new format.
Bug: v8:10445
Change-Id: I7520985499c91c6571ba93e1515223f57f0d38ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253839
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68434}
Until now the breakpointIdToDebuggerBreakpointIds was cleared on page
reload. It keeps a map from breakpointIds to debuggerBreakpointIds,
with the latter being necessary for removing breakpoints.
If a breakpoint is set and we trigger a page reload, the
information about that breakpoint will be removed from the map,
even if it still exists. If we later want to remove the breakpoint
we look into the map, but the meta data is no longer existing.
Thus, reloading the page again will lead to hitting the breakpoint,
even if we removed it in the front-end.
This change keeps the map alive on page reset, so that we still
keep track of set breakpoints after a page reload.
Bug: chromium:1073071
Change-Id: I82192777bac7afc406245a5a1cff0620e8174499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253842
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68433}
evaluate() bypassed CSP for unsafe-eval by default. This is a useful
option for debugging clients, but is not always what we want.
e.g. in the devtools console we want to match the page's CSP settings
to make debugging CSP issues on the page easier.
Add a toggle that keeps the current behavior by default.
Bug: chromium:1084558
Change-Id: Ia01142d5be00f8ef5f65e5eeba17549efc6f9120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250245
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68432}
We rely on Liftoff for debugging, hence enable it everywhere by default.
This follows a chromium finch experiment and a CL to enable it
everywhere in chrome: https://crrev.com/c/2252100R=ecmziegler@chromium.org
Bug: chromium:1040030
Change-Id: I3abbf915515883e6eb1f37501466290def57862d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252196
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68431}
Make sure that the workers do not start running before the main thread
told them so by setting the memory to the first element in the sequence.
Otherwise it can happen that the main thread resets the memory after the
workers already started doing their updates, which results in a hang
(see linked bug).
R=marja@chromium.org
Bug: v8:10625
Change-Id: I959018279e0049900d44457b72146bc37a12bcb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252191
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68429}
This is a reland of e0c1a349ea
The issue was passing SentinelPointer (== +1) through T*.
The fix is disabling cfi unrelated cast diagnostic for the bottlenecks
(Get()). This means that nullptr is treated the same as
kSentinelPointer.
The alternative would be a DCHECK that Get() does not return
kSentinelPointer and adjusting all Member and Persistent logic that
uses Get() to work on void*. This is quite intrusive as it involves
Swap(), heterogeneous assignments, comparisons, etc.
Original change's description:
> cppgc: Properly clear (Weak)Peristent and WeakMember pointers
>
> The CL addresses two issues with (Weak)Persistent and WeakMember:
> 1. (Weak)Persistent pointers are cleared on heap teardown. Before this
> CL the pointers would contain stale values which could lead to UAF.
> 2. WeakPersistent and WeakMember are cleared using a combination of
> internal clearing methods and mutable fields which avoids the use
> of const_cast<>.
>
> Bug: chromium:1056170
> Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68394}
Bug: chromium:1056170
Change-Id: I3d74b43464c2973df1956f51b1419d755dd9f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250240
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68426}
This CL introduces one-letter shorthands to HeapTypes, and fixes
signatures to be in sync with the ValueType and HeapType shorthands.
Bug: v8:7748
Change-Id: I4cc8e26d6523074bc36bf2d29289e63a23e80ddc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249672
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68425}
Rolling v8/build: 78f36d4..3591130
Rolling v8/buildtools: 3200e0f..1ed9957
Rolling v8/buildtools/linux64: git_revision:fbe7aec770944d17c9f3006f6cbb5c19e8cd43ea..git_revision:7d7e8deea36d126397bda2cf924682504271f0e1
Rolling v8/third_party/aemu-linux-x64: T98d0T9VlsHV98PPahwzBa8kF94z5dghLKOTUDCTmwYC..UoYLOT0X6577j70eB9nPqYQs9Z3Nh5lA4I-pRtTchO0C
Rolling v8/third_party/android_sdk/public: CR25ixsRhwuRnhdgDpGFyl9S0C_0HO9SUgFrwX46zq8C..uM0XtAW9BHh8phcbhBDA9GfzP3bku2SP7AiMahhimnoC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/fbbd9ca..4ac015d
Rolling v8/third_party/depot_tools: 3eb899a..2410c84
Rolling v8/third_party/icu: 9e7dae8..79326ef
Rolling v8/tools/clang: 0d67b22..42b285fTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I3024219a33b862fef5e7393a3e18c88f46e29dc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253105
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#68421}
Prototype f32x4.ceil on ARM for both ARM v7 and ARM v8. ARM v8 has
support for vrintp, and for ARM v7 we fallback to runtime.
Since ARM v8 uses vrintp, which is the same instruction used for F32
Ceil (scalar), wasm-compiler reuses the Float32Round check, rather than
creating new F32x4Round optional operators.
Implementation for vrintp (Advanced SIMD version that takes Q
registers), assembler, disassembler support. Incomplete for now, but
more will be added as we add other rounding modes.
Bug: v8:10553
Change-Id: I4563608b9501f6f57c3a8325b17de89da7058a43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248779
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68419}
Similar to chromium side change: https://crrev.com/c/1961070.
When checkout_clang_tidy is set, we will check out clang-tidy via
clang/scripts/update.py.
The goal is to be able to run clang-tidy using Tricium.
Bug: chromium:1087565,v8:10488
Change-Id: I14ebaaca33ca20d59d9cc5e537826829608a1e6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242257
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68418}
Extend gm.py to support long flags (starting with --), which are treated
as test runner flags, and passed unchanged. These flags must be as
single word, '--progress=verbose' instead of '--progress verbose', as gm
only does simple one-at-a-time args parsing.
Change-Id: Icfa161ff231715d0b7eb3ba259fca35a65c68964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250875
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68416}
When preparsing and detecting a sloppy block function redefinition then
don't mark the variable as assigned to make it consistent with the eager
parser.
Bug: chromium:1053364
Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68415}
Change-Id: I2cc4126c63238ddbd4f8bd784e0f7b1322c003ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238028
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68414}
Instead of creating temporary {std::vector}s (which always allocate on
the heap) create more vectors on the stack, via initializer lists.
As this is "only" a fuzzer, performance is not really critical, but
still has some impact on the efficiency of the whole fuzzer.
That said, this CL is mostly a cleanup to replace unwanted code pattern
by better code.
R=jkummerow@chromium.org
Change-Id: I924c15e5d64ed584fc96c85715eef1dca5aef150
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249928
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68413}
At this point in development, this is a reasonable config for the nci
test variant.
--turbo-nci currently disables some compiler phases and avoids
embedded context-dependent constants.
--turbo-collect-feedback-in-generic-lowering enables full feedback
collection in generic lowering.
I'm keeping the two as separate flags for now since it can be
interesting to benchmark --turbo-nci both with- and without feedback
collection.
Bug: v8:8888
Change-Id: I678baeb0ed051b158ac0634f00de9b6a55f87e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247770
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68411}
This changes PrepareFunctionForOptimization to have the same checks
as OptimizeFunctionOnNextCall, as otherwise fuzzing runs into
the DCHECK with a bad number of arguments.
Bug: chromium:1094866
Change-Id: Ief7d428a12139c47a74607d39792276a2eae4ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250255
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68410}
Motivation:
Changes to the typed function references and gc proposals solidified
the notion of heap type, clarified nullable vs. non-nullable reference
types, and introduced rtts, which contain an integer depth field in
addition to a heap type. This required us to overhaul our ValueType
representation, which results in extensive changes.
To keep this CL "small", we do not try to implement the binary encoding
as described in the proposals, but rather devise a simpler one of our
own (see below). Also, we do not try to implement additional
functionality for the new types.
Changes:
- Introduce HeapType. Move heap types from ValueType to HeapType.
- Introduce Nullability for reference types.
- Rework ValueType helper methods.
- Introduce rtts in ValueType with an integer depth field. Include depth
in the ValueType encoding.
- Make the constructor of ValueType private, instead expose static
functions which explicitly state what they create.
- Change every switch statement on ValueType::Kind. Sometimes, we need
nested switches.
- Introduce temporary constants in ValueTypeCode for nullable types,
use them for decoding.
- In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
- Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
subtyping.
- kWasmFuncRef initializers are now non-nullable. Initializers are
only required to be subtypes of the declared global type.
- Change tests and fuzzers as needed.
Bug: v8:7748
Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68408}
This reverts commit f78d69fa5d.
With https://chromium-review.googlesource.com/c/v8/v8/+/2243216,
incorrect MemoryChunk::FromHeapObject uses are now fixed.
Original change's description:
> Revert "[heap] Make ReadOnlySpace use bump pointer allocation"
>
> This reverts commit 81c34968a7 and also
> 490f3580a3 which depends on the former.
>
> Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
> Original change's description:
> > [heap] Make ReadOnlySpace use bump pointer allocation
> >
> > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
> > is now a BaseSpace. BasicSpace is a new base class that Space inherits
> > from and which has no allocation methods and does not dictate how the
> > pages should be held.
> >
> > ReadOnlySpace unlike Space holds its pages as a
> > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
> > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
> > cannot be held in a heap::List. This is desirable since with pointer
> > compression we would like to remap these pages to different memory
> > addresses which would be impossible with a heap::List.
> >
> > Since ReadOnlySpace no longer uses most of the code from the other
> > Spaces it makes sense to simplify its memory allocation to use a simple
> > bump pointer and always allocate a new page whenever an allocation
> > exceeds the remaining space on the final page.
> >
> > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
> > Commit-Queue: Dan Elphick <delphick@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68137}
>
> TBR=ulan@chromium.org,delphick@chromium.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68211}
TBR=ulan@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68407}
When running in single-process mode for Webview, the stack limit is
initialized from a point closer to the top of stack limit. This causes
can cause crashes since the stack limit might be higher than the actual
native stack limit (which is 1MB on Android). As such, use the same
slightly lower stack limit on Arm64 as we do on Arm to give more slack.
BUG=v8:10575
Change-Id: I0cdd0cb4b38aafcb4e158ed639ecf3bba2edb785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250241
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68405}
f89ea875..8d3dd2d
8d3dd2d Sync the test w/ changes in intl-datetime-style 43 by Frank Tang · 15 hours ago master
2dcdba9 Simplify tests by Alexey Shvayka · 15 hours ago
23417d9 Test %TypedArray%.prototype.set with primitives by Alexey Shvayka · 15 hours ago
Bug: v8:7834
Change-Id: I39b62aa1f4800349a009035e704bd4a93223174b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2251174
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68404}
Instead of having a loop with one big switch for handling the different
opcodes, split the decoding into one handler per opcode and call them
via an opcode handler table.
The compiler will generate similar code for this new approach (the big
switch is also compiled into a table lookup and an indirect jump). The
main difference is that it's now calls instead of jumps. This has a
slight performance impact, but allows to look at the decoding logic of
individual opcodes in isolation and see optimization opportunities much
easier. It also allows spot very easily in profilers on which opcodes
most time is spent.
The different opcode handlers are still implemented via the same switch
as before, but since the opcode is a template argument (hence static)
the compiler will eliminate the switch and generate the small handlers
we want.
I plan to actually remove the switch and break up the big generic
{DecodeOp} method into one method per opcode.
R=thibaudm@chromium.org
Bug: v8:10576
Change-Id: Ic2c1e2fe5e98df52a7079ace305cf77340dcbf35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249664
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68403}
This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.
We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.
Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
The {NextInstruction} method is quite hot, since it's called for every
since Wasm instruction. It currently does several checks to figure out
if
- a breakpoint needs to be emitted,
- extra source positions are needed, or
- tracing is active.
The first two can only happen if we are generating debug code, hence
check for that first. The last can only happen in debug mode, so it's
not an issue in production.
Finally, outline the emission of debug information. This leads to
inlining of the {NextInstruction} method into callers, where it is a
single check followed by a call to {EmitDebuggingInfo} (in release
mode).
R=thibaudm@chromium.org
Bug: v8:10576
Change-Id: I5047406f55cd14c6c639528ef6e3422af27d16b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249671
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68399}
https://github.com/tc39/ecma262/pull/1776 is a normative change that
reached consensus in the November 2019 TC39. It changes
%AsyncFromSyncIteratorPrototype% methods to forward the absence of
arguments to the underlying sync iterator. This is observable via
`arguments.length` inside the underlying sync iterator.
For example, .next is changed to, roughly:
```
%AsyncFromSyncIteratorPrototype%.next = function(value) {
let res;
if (arguments.length < 1) {
res = [[SyncIteratorRecord]].[[Iterator]].next();
} else {
res = [[SyncIteratorRecord]].[[Iterator]].next(value);
}
// ...
};
```
Bug: v8:10395
Change-Id: Ib8127d08cd78b8d502e6510241f3f13fbbaba5c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247041
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68398}
