5b92f91ccd
In the ElementsAccessor fast-path for Array.prototype.includes, we iterate backing-store elements according to start and length numbers which might or might not be within the JSArray::length field, for example when side-effects changed the receiver while start and length are computed. So even when we have a packed ElementsKind, we might still observe the hole. This is fine, since logical out-of-bounds accesses are safe in this case, but it means we must not rely on the ElementsKind telling us if we can encounter holes. Bug: chromium:897098 Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8 Reviewed-on: https://chromium-review.googlesource.com/c/1293571 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56884} |
||
---|---|---|
.. | ||
benchmarks | ||
cctest | ||
common | ||
debugger | ||
fuzzer | ||
inspector | ||
intl | ||
js-perf-test | ||
memory | ||
message | ||
mjsunit | ||
mkgrokdump | ||
mozilla | ||
preparser | ||
test262 | ||
torque | ||
unittests | ||
wasm-js | ||
wasm-spec-tests | ||
webkit | ||
BUILD.gn |