This makes sure that the {WasmModuleObject} has been allocated before
any debug events are fired. Since {WasmScript} objects reference the
module object, it needs to be allocated earlier by now.
R=ahaas@chromium.org
TEST=debugger/regress/regress-crbug-840288
BUG=chromium:840288
Change-Id: I02783ce126c463ac953eb2192acb65f3a5d420a1
Reviewed-on: https://chromium-review.googlesource.com/1050246
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53084}
This reverts commit e084eea628.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:840757, v8:7738
Reviewed-on: https://chromium-review.googlesource.com/1051265
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53082}
In wasm we often don't have a SharedFunctionInfo associated with a
compilation job, so we can't get a Script. Just print "unknown" in
these cases (instead of crashing).
R=titzer@chromium.org
CC=herhut@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
Reviewed-on: https://chromium-review.googlesource.com/1049632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53080}
D8 enables the Wasm trap handler by default now, but we need to make sure the
older bounds check case still gets test coverage too, as bounds checks will
continue to be a supported configuration.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I5b0bdded6929a9b3a8480e87d038398b8d2a0fd8
Reviewed-on: https://chromium-review.googlesource.com/1048835
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53078}
To stay compatible with JSC, Array.p.sort did a post-processing step
that shadowed elements from the prototype chain.
Some time ago, JSC changed and no longer exhibits this behavior. To
preserve comptibility and stay consistent with RemoveArrayHoles,
this CL removes this post-processing step altogether and adjusts
tests to expect the new behavior.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: Iecedc37cea25001d3768b99a3a9de3a2db90ba82
Reviewed-on: https://chromium-review.googlesource.com/1047286
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53066}
This CL implements the functionality of SafeRemoveArrayHoles (JS),
which is used as a pre-processing step for sorting, in a runtime
function.
SafeRemoveArrayHoles is a generic fallback, when an existing runtime
function fails to remove holes/move undefineds to the end of an array.
This CL extends the existing runtime function to also support JSProxy
objects, and objects where indices have accessors.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: I4881539cf2171caba08ff6e3e50320291f49839c
Reviewed-on: https://chromium-review.googlesource.com/1041950
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53060}
The hard-coded timeout in the test is so near, that e.g., adding DCHECKs pushes
the test over the limit. The test is ran with dcheck_always_on=true.
We shouldn't do any performance testing with dcheck_always_on=true; this creates
the wrong incentive to not add DCHECKs (or in this case, CLs which add more
DCHECKs or cause more DCHECKs to be hit cannot land at all).
Change-Id: Ia4d1b2b17ce5a5330b929f984253c89ba273f661
Reviewed-on: https://chromium-review.googlesource.com/1046548
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53032}
In order to get more test coverage (also on ClusterFuzz), stage Liftoff
and tier up behind --future.
R=hablich@chromium.org
CC=titzer@chromium.org
Bug: v8:6600
Change-Id: I718e17957b26f60aa4c002333035f693344806e0
Reviewed-on: https://chromium-review.googlesource.com/1042385
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52987}
This is a reland of a0c57368a9
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
Change-Id: I9854400bfc1d22bd258f17118fcb7460cdc3acd5
Reviewed-on: https://chromium-review.googlesource.com/1043786
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52985}
Since 94ce16b704, when loading an iterator from null or undefined, we
generate the error message "x is not iterable" instead of the unwieldy
"Cannot read property 'Symbol(Symbol.iterator)' of undefined". However
Runtime::GetObjectProperty, which is used as slow path by LoadICs, did
not check for this case, leading to different messages being generated
depending on IC state.
Bug: chromium:823130
Change-Id: Ie98500b97efef401aac9880b9af47d58c3c2825d
Reviewed-on: https://chromium-review.googlesource.com/1042951
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52974}
This reverts commit a0c57368a9.
Reason for revert: Speculative revert due to failures with custom
snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/19061
Local bisect also points to this change:
http://shortn/_IhVxU2FKLu
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I1830e6ce14314f06f918a0c428182bfd68354ad9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1041968
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52949}
This moves the link from a {WasmInstanceObject} to its corresponding
{WasmModuleObject} into the right place and also makes it strong. This
ensures that an instance always keeps the underlying module alive and
hence removes the situation of an "orphaned instance".
R=clemensh@chromium.org
Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
Reviewed-on: https://chromium-review.googlesource.com/1041691
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52942}
The first element of a given iterable argument can be a hole. Thus,
normalize the first element so that we can correctly format the
exception message with "undefined" for a hole element, instead of "NaN".
Bug: v8:7715
Change-Id: I62edd09e361ebeebab642bb82db29b73a2c7b193
Reviewed-on: https://chromium-review.googlesource.com/1038951
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52917}
We incorrectly used a TurboFan typer check for {0,10,undefined} on the
radix argument on Number.parseInt, which was internally widened to the
checking whether radix is in range 0-10 or undefined. This CL introduces
two separate checks.
Bug: chromium:838766
Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83
Reviewed-on: https://chromium-review.googlesource.com/1039197
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52914}
A stack overflow can be thrown by JSEntryStub, which means the
thread-in-wasm flag will not have the expected value. To accommodate
this, we now clear the flag during exceptional returns if it is set.
Bug: chromium:834624
Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb
Reviewed-on: https://chromium-review.googlesource.com/1019570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52891}
assertPromiseResult caused tests to timeout when the result of the
promise was unexpected, e.g. rejected instead of the expected
fulfillment. This CL cleans up the implementation of
assertPromiseResult, adds better stack traces, and adds tests for all
the important cases I can think of.
R=mathias@chromium.orgCC=clemensh@chromium.org
Bug: v8:7570
Change-Id: I6ecb94fd3e5151502edf73c3bcdeb518b80fc81c
Reviewed-on: https://chromium-review.googlesource.com/1032786
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52882}
Without this change, we could disable slow paths required when symbols
such as toStringTag are present on a receiver, but accessors or
interceptors are not (added in 31800120cc)
This change modifies this behaviour to not unset the previously set bit
if these forced slow path conditions are not met.
BUG=v8:7706
R=bmeurer@chromium.org
Change-Id: Id7bceb0e749da52e2dbcde0a310a865a89f24066
Reviewed-on: https://chromium-review.googlesource.com/1034210
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#52874}
* If the mutability of the global object doesn't match the module, then
it should throw a LinkError.
* There was a missing `return` when importing a Number as a mutable
global.
* All globals were being exported as immutable.
* Attempting to set the value of an immutable global should throw a
TypeError.
* The length of the setter function should be 1.
Bug: v8:7625
Change-Id: I08d6a428506a18db15eecadf4cbcee89e0658924
Reviewed-on: https://chromium-review.googlesource.com/1031626
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52865}
When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.
R=mstarzinger@chromium.org
Bug: chromium:837417
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
In the case of an indirect call to an imported function, the target
instance stored in the IFT was actually wrong.
Bug: chromium:834619
Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2
Reviewed-on: https://chromium-review.googlesource.com/1030174
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52831}
The new spec has two arguments, the first is the global descriptor, and
the second is the initial value:
new WebAssembly.Global({type: i32}, 42);
If the initial value argument is omitted, the value is set to 0.
Bug: v8:7625
Change-Id: I679d4b7c49c69ec7ffcdfeb8ae506fa7ab9bba95
Reviewed-on: https://chromium-review.googlesource.com/1028847
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52822}
This is a reland of f5d308510a
Original change's description:
> [builtins] Introduce further constant & external reference indirections
>
> This introduces further indirections for embedded constants and
> external references for builtins generated by the macro-assembler.
> The used mechanisms (LookupConstant and LookupExternalReference) are
> identical to what we already use in CSA.
>
> Almost all builtins are now isolate-independent in both release and
> debug modes. snapshot_blob.bin is roughly 670K smaller in embedded
> builds vs. non-embedded builds, while libv8.so is roughly 280K larger.
>
> Bug: v8:6666
> Change-Id: I7a6c2193ef5a763e6cf7543dd51597d6fff6c110
> Reviewed-on: https://chromium-review.googlesource.com/1006581
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52810}
TBR=mstarzinger@chromium.org
Bug: v8:6666
Change-Id: I73dfe207f2c5f79a9a06c165c75f5619e88a5a17
Reviewed-on: https://chromium-review.googlesource.com/1030550
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52819}
The WasmInstanceObject stores two new arrays:
- imported_mutable_globals_buffers_: a FixedArray of all the imported
globals' array buffers.
- imported_mutable_globals: a calloc'd array of Addresses pointing to
the mutable global in its array buffer.
When accessing the global, the generated code looks up the address in
imported_mutable_globals to find where to load/store.
Bug: v8:7625
Change-Id: I60844c21a788fce28f346455f10f2283d1c152e9
Reviewed-on: https://chromium-review.googlesource.com/1020602
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52794}
The mutable-globals proposal spec allows importing as Numbers or
WebAssembly.Global values, but always exports as WebAssembly.Global.
Since the value is always boxed, we can also import/export i64 values.
This CL also includes support for export of mutable globals. Since the
underlying ArrayBuffer that stores the global's value is shared between
the module and the WebAssembly.Global object, all that needs to be done
is remove the validation check.
Bug: v8:7625
Change-Id: I24d763e3bc193d229a7cc33b2f2690a473c6f2bc
Reviewed-on: https://chromium-review.googlesource.com/1018406
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52789}
Iterate over all descriptors instead of bailing out early and missing
enumerable properties later.
Bug: chromium:836145
Change-Id: I104f7ea89480383b6b4b9204942a166bdf8e0597
Reviewed-on: https://chromium-review.googlesource.com/1027832
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52786}
WebAssembly.instantiate is polymorphic, it can either take a module
object as parameter, or a buffer source which should be compiled first.
To share code between the two implementations, the module object was
first passed to a promise (i.e. which is the result of compilation).
However, passing the module object to a promise has a side effect if
the module object has a then function. To avoid this side effect I
remove this code sharing and call AsyncInstantiate directly in case
the parameter is a module object.
R=mstarzinger@chromium.org
Bug: chromium:836141
Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4
Reviewed-on: https://chromium-review.googlesource.com/1025774
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52755}
This is a reland of 5728b3fbc5
Original change's description:
> [builtins] Separate species protectors for Array, TypedArray, Promise
>
> Previously, there was one species protector for Array, TypedArray and
> Promise. This CL splits the protector in three separate ones. This means
> that invalidating one of them does not have negative performance
> implications for the other ones.
>
> Bug: chromium:835347, v8:7340
> Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
> Reviewed-on: https://chromium-review.googlesource.com/1023408
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52733}
Bug: chromium:835347, v8:7340
Change-Id: I0c0188a0723e206ddb362834bcf872b23cd7666d
Reviewed-on: https://chromium-review.googlesource.com/1023811
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52742}
This reverts commit 5728b3fbc5.
Reason for revert: Breaks noi18n build
Original change's description:
> [builtins] Separate species protectors for Array, TypedArray, Promise
>
> Previously, there was one species protector for Array, TypedArray and
> Promise. This CL splits the protector in three separate ones. This means
> that invalidating one of them does not have negative performance
> implications for the other ones.
>
> Bug: chromium:835347, v8:7340
> Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
> Reviewed-on: https://chromium-review.googlesource.com/1023408
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52733}
TBR=sigurds@chromium.org,bmeurer@chromium.org
Change-Id: Ied8b436e7991c759eb3b98702c142aa127a7e63c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:835347, v8:7340
Reviewed-on: https://chromium-review.googlesource.com/1024151
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52736}
Previously, there was one species protector for Array, TypedArray and
Promise. This CL splits the protector in three separate ones. This means
that invalidating one of them does not have negative performance
implications for the other ones.
Bug: chromium:835347, v8:7340
Change-Id: Id84aa0071f17096192965264eb60ddadd1e8e73f
Reviewed-on: https://chromium-review.googlesource.com/1023408
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52733}
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.
Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
With certain ICU data bundles (such as the Node.js "small-icu"),
%GetDefaultICULocale() may return a more specific language tag (e.g.
"en-US") than what's available (e.g. "en"). In those cases, consider the
more specific language tag supported.
This CL also resolves the following Node.js issue:
https://github.com/nodejs/node/issues/15223
Bug: v8:7024
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ifda0776b3418734d5caa8af4e50c17cda95add73
Reviewed-on: https://chromium-review.googlesource.com/668350
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52716}
This CL adds a test for each typed element kind where the array to sort
consists of some max/min/zero elements.
When providing a custom compare function, the upcoming torque version
of TypedArray.p.sort needs to convert array elements to Number/BigInt
and back. The tests check the edge cases for that conversion.
R=jgruber@chromium.org
Bug: v8:7382
Change-Id: Ia85ca343f62ece208acdeb1595e94f17ce12b713
Reviewed-on: https://chromium-review.googlesource.com/1021080
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52710}
This makes testing with random gc stress use the status file entrees
for gc fuzzing as well, since many test cases not suitable for one, are
not suitable for the other.
This also skips two more tests that rely on assert(Un)Optimized, which
is unreliable with gc fuzzing.
TBR=sigurds@chromium.org
Change-Id: I33a617b251d5cf65cf6e486d07ec55cde050b8ab
Reviewed-on: https://chromium-review.googlesource.com/1021082
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52701}
In ArrayBuiltinsAssembler::VisitAllFastElementsOneKind(), we enumerate
an arrays elements, carefully checking for the "hole" when required.
This code is only called for arrays whose prototype is the initial array
prototype. And the path is only available when the initial array
prototype is free of elements. Since that's the case, we only need to
verify that the initial array prototype remains free of elements during
an iteration with javascript callbacks. We don't need a body of code
that can walk the prototype chain looking for elements visible through
the "hole" value. In practice, this code was never run.
Change-Id: Iba5e275c559d495aa1cf6a4f29d66e2ce475c981
Reviewed-on: https://chromium-review.googlesource.com/1015023
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52660}
