Expressions in class heritage position do not have access to the
inheriting class's private names, only its lexical bindings. The parser
currently uses the same scope chain for both.
This CL makes scopes in class heritage position skip their outer class
when resolving private names. Whether a scope needs to skip is kept as a
bit on various scope-related data structures.
See implementation doc at
https://docs.google.com/document/d/1d3o_SQqcICxfjLMw53OOaiIQux0ppNHQJnjZHtCQLwA
Bug: v8:9177
Change-Id: I77e491a9d4a261131274f12ddf052af7ac31a921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769486
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63586}
{JavaScriptFrame::GetParameters} allocates a new {FixedArray}, hence
all object references need to be handified to survive that allocation.
R=mstarzinger@chromium.org
Bug: chromium:1000635
Change-Id: I76df5ac109bdb6999fe897bdafaf2175344ecca4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787429
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63583}
This is a reland of 981aafaf97
It adds double checks to LoadFieldByIndex in the optimizing compiler, which
are likely the source of the crashes.
Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a69.
> This is a reland of 7e1fbe8f34.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}
TBR=verwaest@chromium.org
Bug: v8:9606
Bug: chromium:997989
Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63582}
Implements match indices for regexp, as specified by
https://github.com/tc39/proposal-regexp-match-indices,
a stage 3 TC39 proposal. This implementation is hidden
behind the '--harmony-regexp-match-indices' flag.
Regexp match indices extends the JSRegExpResult object
with an array of indices of matches, as well as a
dictionary of capture names to match indices.
Bug: v8:9548
Change-Id: Ia9efcee00d997dda6158539b8d0f4c4e5965e5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771379
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63581}
This is a safe to merge hot-fix to tackle https://crbug.com/983764.
To be reverted after merging to M77.
Bug: chromium:983764
Change-Id: I3cd27481f224b352ef6bcf9dde21a8f77616acff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1786285
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63570}
Async functions were not correctly fixed up for code coverage, which
caused an additional uncovered range to be reported between a return
statement and the closing bracket.
This CL adds code that detects such ranges, and removes them, similarly
to how the ranges are removed for normal functions. The removal process
is different, because the parser rewrites async functions to contain a
try-catch handling promise rejection.
Change-Id: I73b08d64be74d26c32f2f9652d027430d4671251
Bug: chromium:981313, v8:8381
Change-Id: I82a7f0c54d3a48609ef5255a7659d9557e163566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782837
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63561}
This is a reland of ab089c7864, after
making a flaky test more robust.
Original change's description:
> [turbofan] Prepare for moving part of CreateGraph into the background
>
> - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
> (get it from SFI instead).
> - Add some fields to FeedbackVectorRef that are needed to avoid heap access
> in BytecodeGraphBuilderPhase.
> - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
> than just the feedback slots.
> - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
> that CreateGraph is last.
>
> Bug: v8:7790
> Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63515}
Bug: v8:7790
Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63545}
Use the position of commas in async arrow expressions to mark the
initializer position of any parameters that might have been set in the
preceding parameter.
This extends https://chromium-review.googlesource.com/c/v8/v8/+/1710671
to async arrow heads.
Bug: v8:8510, chromium:997320
Change-Id: I98e0ac817c7f53fbf1dced98fb6891a386ee7803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781057
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63542}
This reverts commit 8b89a7c32d.
Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}
TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.
Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
This CL adds initial tests for the tier-up logic.
Change-Id: I6e6ff69604b14387e81b08d178f98d2227b4f496
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776080
Commit-Queue: Ana Pesko <anapesko@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63503}
This is a reland of 0736599a69.
This is a reland of 7e1fbe8f34.
Original change description:
> [ic] In-place Double -> Tagged transitions
>
> With no more MutableHeapNumber, we can make Double -> Tagged transitions
> in-place, at the cost of an extra map check when accessing double fields
> to make sure they are still doubles.
>
> Bug: v8:9606
> Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63374}
TBR=verwaest@chromium.org, tebbi@chromium.org
Bug: v8:9606
Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63499}
When changing the code coverage or type profiler modes, first ensure
there are source positions for all BytecodeArrays as regenerating the
source positions after toggling the mode will result in a bytecode
mismatch.
Bug: v8:9656, v8:8510
Change-Id: Ic6cf3afec1588f11e5ce5fcbea2fd13e4452e15f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774721
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63484}
This patch implements the access of private accessors by loading the
referenced component from the AccessorPair associated with private
name variables. It also makes the error messages for invalid kind
of private accessor access more specific.
Bug: v8:8330
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Change-Id: I6d441cffb85f8d9cd0417ec9b6ae20f3e34ef418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695205
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63474}
This reverts commit 62e168308c.
Reason for revert: it will be relanded after branch
Original change's description:
> Reland x5 [arraybuffer] Rearchitect backing store ownership
>
> This reverts commit 8fdb23873b.
>
> Original change's description:
> > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
> >
> > This is a reland of bc33f5aeba
> >
> > Contributed by titzer@chromium.org
> >
> > Original change's description:
> > > [arraybuffer] Rearchitect backing store ownership
> > >
> > > This CL completely rearchitects the ownership of array buffer backing stores,
> > > consolidating ownership into a {BackingStore} C++ object that is tracked
> > > throughout V8 using unique_ptr and shared_ptr where appropriate.
> > >
> > > Overall, lifetime management is simpler and more explicit. The numerous
> > > ways that array buffers were initialized have been streamlined to one
> > > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > > and the construction and destruction of the BackingStore object itself
> > > handles the underlying page or embedder-allocated memory.
> > >
> > > The embedder API remains unchanged for now. We use the
> > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > > keep the backing store alive properly, even in the case of aliases
> > > from live heap objects. Thus the embedder has a lower chance of making
> > > a mistake. Long-term, we should move the embedder to a model where they
> > > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > TBR=yangguo@chromium.org
> >
> > BUG=v8:9380,v8:9221,chromium:986318
> >
> > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63041}
>
> TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
>
> Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63461}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63471}
This reverts commit 8fdb23873b.
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63461}
Sloppy eval extends the outer declaration scope's context. This is also
true for sloppy eval inside of other sloppy evals -- the outer declaration
scope's context is extended rather than the outer sloppy eval's
declaration scope. However, we consider eval scopes to also be declaration
scopes, for the purposes of strict eval and caching lookup variables. So,
we need to make sure that we skip through sloppy eval scopes when marking
a scope as calls_sloppy_eval.
In fact, we implement this rather as never marking sloppy eval scopes as
calls_sloppy_eval, under the assumption that the parent scope will already
have been marked calls_sloppy_eval by the outer eval.
As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
RecordEvalCall(), rename the variable to something more meaningful, and
make Snapshotting to use a new calls_eval bit on Scope.
Bug: chromium:996751
Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63455}
This CL try to use a phi as a branch condition if the control flow from the
branch is known from previous conditions. This change will open up more branch
folding opportunities for later pass.
Change-Id: I26316ab3a68c2d58d0df53691981288a996d4ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674484
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63434}
Currently the backing store and elements kind might not aligned aka
backing store can be dictionary where elements kind is frozen/sealed
element kinds or the other way around. The reason is that
Object.preventExtensions change elements kind to DICTIONARY while
Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
Apply both these operations can lead to that problem as in
chromium:992914
To solve this issue, we avoid Object.preventExtensions to change backing
store to dictionary by introducing new nonextensible elements kind.
These new nonextensible elements kind are handled similar to frozen,
sealed element kinds. This change not only fixes the problem but also
optimize the performance of nonextensible objects.
Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
Bug: chromium:992914, v8:6831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63432}
This change allows the KeyAccumulator to throw a range error if there
are too many properties to be enumerated.
This CL introduces extensive checks during key enumeration in the run-time,
and might introduce regressions. If so, feel free to revert.
Bug: chromium:918301
Change-Id: I6166c0b15f1a05eac7116a979f12ba4833d1d1b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545902
Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63430}
This fixes an invalid assumption when emitting code for matching '^'
(start of line) in multiline regexps and '\b', '\B' in general.
What we used to do: if the current trace's cp_offset (the offset from
the current position) was non-zero, we assumed that we were looking at
subject string index 1 or greater (i.e.: not at the start of the string
or before).
This is no longer valid since cp_offsets can now be negative.
This CL changes the logic to omit start- and bounds-checks only for
strictly positive cp_offsets, where the above assumption still holds.
Bug: chromium:996391
Change-Id: I79be4fc295c6f0b63e41c13d1e91fdd00f2f2b42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771794
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Erik Corry <erikcorry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63424}
By marking maps detached from the transition tree as prototypes, we'll
automatically stop tracking transitions from those detached fast maps. That
allows us to quickly check whether a map is detached (or the initial map
anyway); and saves memory. We can use this information to ignore sibling type
feedback when parsing a JSON array with many distinctly shaped json objects.
Bug: chromium:993980
Change-Id: I86d493ac2cabec2c31c6e322ad5c5a7ace059dfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771778
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63403}
For stores with Double feedback, StoreIC needs to check that the
representation is still Double before doing the store, in case it
accidentally tries to write to an object or worse, mutate a non-mutable
HeapNumber.
Bug: v8:9606
Bug: chromium:997485
Change-Id: I51e0953b40f752648c5e86b8644c23baf636367e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768373
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63402}
This reverts commit 9460101cdb.
Reason for revert: Causes confusion on Blink side, as it introduces
an object with >=2 internal fields that is not a wrapper (see bug).
Bug: chromium:996681
Change-Id: I275b5a064a4ee8c73c05f97be322924a3bc5370e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769148
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63386}
Even when a field is marked const, we may emit multiple consecutive in-literal stores to that field. That is, in 'JSNativeContextSpecialization::BuildPropertyStore', when the access mode is 'kStoreInLiteral' and we are accessing a const field, we may produce a StoreField node, even though another StoreField (that stores something other than 'Uninitialized') to the same const field dominates it. This appears to be sound, since earlier stores to literals cannot be observed anyways.
Unfortunately this behavior conflicts with the double const store invariant in load elimination: Roughly speaking, we assume that load elimination may never observe two consecutive const stores to the same field on the same object.
The apparent solution would be to treat 'kStoreInLiteral' accesses like regular 'kStore' accesses: For consecutive stores to const properties we don't emit StoreField, but instead emit code that checks whether the value about to be written is equivalent to the previously written one, and otherwise deopt ('DeoptimizeReason::kWrongValue'). Unfortunately this turns out impractical, since for 'kStoreInLiteral' accesses we can't easily decide whether we're dealing with the first such store or one of the consecutive ones. Also see this abandoned CL: https://chromium-review.googlesource.com/c/v8/v8/+/1762020.
This CL instead adds an exception to the invariant in load elimination. We track whether a store arose from a 'kStoreInLiteral' access, and use this information when visiting StoreField nodes in load elimination.
R=neis@chromium.org, tebbi@chromium.org
Bug: chromium:987205
Change-Id: I8829752aa0637e9599677d20aad2d706d40d7fe6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763535
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#63385}
This reverts commit 5db04cc0dd.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Revert "[regexp] Only append to JSRegExpResult's initial map if we add descriptor"
>
> This reverts commit dc1cc2232b.
>
> Revert "[regexp] Implement the match indices proposal"
>
> This reverts commit 9460101cdb.
>
> Reason for revert: Causes confusion on Blink side, as it introduces
> an object with >=2 internal fields that is not a wrapper (see bug).
>
> Bug: chromium:996681
> Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63376}
TBR=yangguo@chromium.org,sigurds@chromium.org,joshualitt@chromium.org
Change-Id: Ic58fc3fc83faaf86bd895da29eacb7d51c443beb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:996681
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768584
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63379}
With this Cl, a function that has been marked for deoptimization will
not be reported as optimized. This protects against potential races
where an mjsunit tests assertUnoptimized, and the optimized code for
the function has been marked for deoptimization, but not been disposed
of yet.
The potential for this race has been discovered in the context of bug
v8:9563, but this CL is not a fix for that bug.
Change-Id: I89d8aa85f19033e6b823324b3307b95d61367147
Bug: v8:9563
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763543
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63377}
This reverts commit dc1cc2232b.
Revert "[regexp] Implement the match indices proposal"
This reverts commit 9460101cdb.
Reason for revert: Causes confusion on Blink side, as it introduces
an object with >=2 internal fields that is not a wrapper (see bug).
Bug: chromium:996681
Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63376}
In order to reflect web reality, TC39 has made some slight changes to
name descriptors, see https://github.com/tc39/ecma262/pull/1490 for
details. V8 was mostly already in compliance with these changes, but
ThrowTypeError and anonymous classes needed some slight changes.
Bug: v8:9646
Change-Id: I163238954938f0c005e3adbc61b90498e01436da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63373}
While we only need to check stability of the receiver map if its
inference was "unreliable", we must check stability of each prototype's
map unconditionally.
Bug: chromium:997100
Change-Id: I20071ac9eb74c810ad2ab1d78abfb54a1a006c29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768576
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63364}
This preserves the object identity of a {WebAssembly.Function} instance
that is being re-exported by a module. Such functions are considered to
have an internal [[FunctionAddress]] slot and hence require their object
identity to be preserved (similar to {WasmExportedFunction} already).
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88ba75fcd91ce04440008467f3b218a1ac3047db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763545
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63346}
For import wrappers, we add a special "callable" parameter as the last
parameter. This parameter is not set in the TurboFan graph but in the
code generator. Therefore this parameter has to be allocated in a
special register and cannot be lowered generically. With this CL we
detect in the CallDescriptor lowering if the last parameter is this
special "callable" parameter. If so, we preserve it in the lowered
CallDescriptor in the same register.
R=jkummerow@chromium.org
Bug: v8:7741
Change-Id: I884baa41813011c811612ec84f4e3cfe86a0e83a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762014
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63344}
This CL adds a mechanism that prevents the RuntimeProfiler from
triggering optimization of a function after
%PrepareFunctionForOptimization has been called. This is useful to
prevent flakiness in tests, as sometimes a function that already
got deoptimized would receive a new code object from a concurrent
compile that was triggered by a heuristic just in the right moment
for the assertUnoptimized test to fail. For example, the following
was happening:
PrepareFunctionForOptimization
[marking `testAdd` for optimized recompilation, reason: small function]
[concurrently compiling method `testAdd` using TurboFan]
[manually marking `testAdd` for non-concurrent optimization]
[synchonously compiling method `testAdd` using TurboFan]
[synchonously optimizing `testAdd` produced code object 0xAAAA - took 1.638 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xAAAA)
DeoptimizeFunction `testAdd` with Code Object 0xAAAA
[concurrently optimizing `testAdd` produced code object 0xBBBB - took 3.377 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xBBBB)
Bug: v8:9563
Change-Id: Ia4c846aba95281589317d43b82383e70fe0a35f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763546
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63343}
This CL was reviewed originally in https://crrev.com/c/1518181.
Bug: v8:7741
Change-Id: Iddb139a24c4b9aee6694e20cb5d04e9f9887160c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752859
Auto-Submit: Sven Sauleau <sven@cloudflare.com>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63321}
This CL implements the nullish operator in bytecode as defined by:
https://github.com/tc39/proposal-nullish-coalescing. It can be
enabled by passing '--harmony-nullish'.
Nullish is similar to logical operators, but instead of truthy/falsey
values, it short circuits when it evaluates a null or undefined value.
Bug: v8:9547
Change-Id: Ia0f55877fc2714482b5547942baef9733537d1b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738568
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63317}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88a6c7e9236a549808707c72e40a63302b7747a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763527
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63312}
This just adds a test case checking against the current behavior, but
expectations might change once the proposal is clarified. For details
see: https://github.com/WebAssembly/js-types/issues/11R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I2fc502460c0a8094a414d138703b75497b2d1c6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762517
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63311}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic51b7b4744f7b3ad056a778aecfc4614ca8d6e75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762019
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63299}
Since the mutability of HeapNumbers is determined by their owning
object's descriptor array, we can remove the MutableHeapNumber type
entirely, at the cost of a few fewer DCHECKs and a couple of TODOs
to use the descriptor array information.
This is a necessary step towards a follow-up which allows in-place
Double -> Tagged transitions
Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/
Bug: v8:9606
Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63294}
This patch implements the declaration of private accessors.
When iterating over the class properties, we track private
accessors associated with the same name in a ZoneHashMap.
Once we get to all the necessary components for a private name
(we know statically whether we should expect only a setter,
only a getter, or both), we emit a call to a runtime function
`CreatePrivateAccessors` that creates an AccessorPair, and
store the components in it. The AccessorPair is then associated
with the private name variable and stored in the context
for later retrieval when the private accessors are accessed.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63284}
Fixes bytecode mismatch between lazy and non-lazy where "this" was
marked as maybe assigned in constructors that called the super
constructor. Since this will return the hole in cases where it was not
yet initialized by super (and the hole is explicitly handled by
JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as
a constant in all cases. In the case of lazy compilation case, "this"
is never added to the ScopeInfo so is never seen as mutable.
Bug: chromium:994719
Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63283}
