This isn't used outside of tests, so let's just remove it.
Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75220}
This also removes intrinsics that were just used in tests. It keeps
InlineIncBlockCounter for now because it's a less straightforward.
Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75217}
- Add new Builtin enum
- Move Builtins::Name:kXXX to Builtin::kXXX
- Update existing code
Follow CLs will unify the mix of using int builtin-ids and
Builtins::Name to only use the new Builtin enum and changing it to
an enum class.
Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74995}
They have been disabled for some time and are superseeded by lazy
feedback vector allocation.
Change-Id: Iafc3989b0c1f866ce7d6295d9b13ccaa5ef1c115
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905609
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74711}
The logic is different for shared and non-shared memory, so it's
cleaner to have different functions for them.
Bug: v8:11111
Change-Id: I95d43b54c207b8059ea59d6d0f873623de946be3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903152
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74656}
Order the bytecodes to enable range-based checks for
IsWithoutExternalSideEffects. Also remove the now unecessary
macro definitions for Jump bytecodes.
BUG=v8:9684
Change-Id: Id2d7e2e0141b57864c65a752bc233f004f86f760
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2875208
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74397}
Previously we'd attach source positions to implicit returns that are
generated when leaving an async function with a promise rejection. This
was due to the use of `kNoSourcePosition` on the `end_position` in the
`ReturnStatement` nodes as indicator to pick the return position from
the function literal, instead of really not putting a source position on
that specific `Return` bytecode.
This CL adds a dedicated marker to `ReturnStatement` to express that the
`BytecodeGenerator` should put the return position from the function
literal there instead of overloading the meaning of `kNoSourcePosition`.
Bug: chromium:901819, chromium:782461
Fixed: chromium:1199919, chromium:1201706
Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74301}
Disable or support --always-sparkplug in various tests that until now
were always expecting only bytecode.
Bug: v8:11420
Change-Id: Ida45041739fb55851aa493c51f1ed796aa1c0606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2786852
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73668}
Calls with a spread expression in a non-final position get transformed
to calls to Reflect.apply. This transformation is currently done in
the parser, which does not compose well with other features (e.g.
direct eval checking, optional chaining).
Do this transform in the BytecodeGenerator instead.
Bug: v8:11573, v8:11558, v8:5690
Change-Id: I56c90a2036fe5b43e0897c57766f666bf72bc3a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2765783
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73534}
Be explicit about source positions for `Return`s in the
BytecodeGenerator, and only do self-healing explicitly in the
`ReturnStatement` translation, where an end position of
`kNoSourcePosition` is turned into the return position of the
function literal.
This allows us to reason more easily about which `Return`s actually
receive a meaningful source position, and in particular it allows us
to construct the internal `Return`s for `yield` and `yield*` with no
source position attached to them. Previously they'd get the source
position for the implicit (final) return attached to it, which confused
the debugger and led to breakpoints being set in the completely wrong
spot.
Considering the simplified example
```
function* foo(){
var a = 1;
}
```
this would previously generate the following bytecode
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
30 S> 38 : Return <=========================== internal Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
where everything between offset 4 and 42 corresponds to the implicit
yield at the beginning of every generator function, in particular the
code between 20 and 42 corresponds to that initial yields resumption
logic. Notice how the internal Return at offset 38 gets assigned the
source position of the function literal (the same as the implicit
return at the end). This confuses the debugger quite a bit when trying
to set a breakpoint on the closing brace, since it's going in bytecode
order and will thus discover the `Return` at offset 38 first (matching
the source position 30 it's currently looking for) and setting the
breakpoint there. This `Return` bytecode however is only executed when
the generator is resumed via `GeneratorPrototype.return()`, and it'll
not hit when the developer uses the generator normally, which is not
the desired behavior and extremely confusing (especially since stepping
on the other hand works as expected).
With this patch, we no longer slap a source position (and in particular
not the function literal's return position) onto these internal
`Return`s as you can see from the generated bytecode below:
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
38 : Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
This also allows us to remove the break position finding hack that was
kept in BreakIterator::BreakIndexFromPosition() for generators and
modules.
Fixed: chromium:901819
Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73119}
It had essentially become a synonym for BytecodeArrayAccessor.
This removes the BytecodeArrayIterator class and renames
BytecodeArrayAccessor to BytecodeArrayIterator.
Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73005}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
This speeds up sparkplug by >20%.
This reland fixes the OffHeapBytecodeArray to also register a GC
callback. Turns out off-heap here doesn't mean that the underlying
bytecode array is off-heap and it can in fact move.
Change-Id: I7c6e82abd2a7be08ead537ab84855e76edc3b290
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688400
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72677}
This reverts commit 60748ee2df.
Reason for revert: Broke Linux64 ASAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/38792/overview.
There are 4 changes in that range causing the failure, I found that this change caused the failure by running locally `./tools/run-tests.py --outdir=out/repro mjsunit/wasm/gc-stress --variant turboprop_as_toptier --random-seed-stress-count 100`.
Original change's description:
> Reland "[interpreter] Speed up the BytecodeArrayAccessor through direct memory access"
>
> Tbr: ulan@chromium.org, neis@chromium.org, leszeks@chromium.org
> No-Presubmit: true
> Change-Id: I4ceb9e21ac7d78a87776b4be174772539d2da8d9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685173
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72632}
TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I441ddfda5d852b7a01f38a9e60edc56f40ae626a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686266
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72635}
Implements https://github.com/tc39/ecma262/issues/2034
Currently the token sequence `for (async of` is ambiguous. It can be the
prefix for either `(async of => {};;);` or `for (async of foo);`. This
CL disallows the token sequence.
Note that `for await (async of` is still allowed, since there is no
C-style `for await (;;)`, and thus no ambiguity.
Bug: v8:11412
Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72607}
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property
accurately. When "eval" is seen, figure out whether it can access
"super" and if yes, set the corresponding home object as needed.
Fix 2: The object literal scope shouldn't be entered for things
inside spreads.
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72422}
This reverts commit f6450b97ec.
Reason for revert: ClusterFuzz bugs
Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}
TBR=marja@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
This change completes support for import assertions for dynamic import().
A new version of the HostImportModuleDynamically callback taking import
assertions is added to the public API. The name is very verbose; we
could consider removing the "ImportAssertions" part when the old API
is removed.
Bytecode generation is updated to pass the assertions, if present, to
Runtime_DynamicImportCall.
Isolate::RunHostImportModuleDynamicallyCallback extracts the assertions
from the options bag, filters out the assertions not present in the
list specified by the host in HostGetSupportedImportAssertions, and
sorts them by code point order of the keys per
https://tc39.es/proposal-import-assertions/#sec-import-call-runtime-semantics-evaluation.
The resulting array is passed to the host in the callback.
Bug: v8:10958
Change-Id: I931df00f954a9f9c65bff5bcf461ba1c8f11e94e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620578
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72307}
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.
2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).
3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.
4) MultipleEntryBlockContextScope was messing up the accumulator
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
This reverts commit 4d5b878b61.
Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263
Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}
TBR=marja@chromium.org,leszeks@chromium.org
Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
Remove the ambient dependency on the currently entered isolate, let the
embedder pass it in explicitly.
Bug: v8:11287
Change-Id: I03690390a308a59e2c6ea5c6ae268780d836b717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608209
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72105}
This CL changes SharedFunctionInfo::GetBytecodeArray to a function
template, which is specialized for Isolate and LocalIsolate arguments.
This allows main thread only uses to avoid taking a lock.
Bug: v8:7790, chromium:1154603
Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71833}
When we know a value passed to BytecodeArrayBuilder::LoadLiteral(double)
can be encoded as a Smi, we create LdaSmi instead of LdaConstant.
Driven by a forgotten Smi::FromInt() in BytecodeGenerator, also fixed in
this CL.
Bug: v8:11278
Change-Id: I4a1ad48e2c9aff8391113812e34dae838a1a38d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595437
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71827}
Scopes in V8 are used to guarantee one or more properties during its
lifetimes. If a scope is not named e.g MyClassScope(args) instead of
MyClassScope scope(args) it will get created and automatically destroyed
and therefore, being useless as a scope. This CL would produce a
compiling warning when that happens to ward off this developer error.
Follow-up to ccrev.com/2552415 in which it was introduced and
implemented for Guard classes.
Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71425}
- Use C++ primitives (int, bool) for the ScriptOrigin constructor.
- Deprecate the old accessors and constructor
Bug: v8:11195
Change-Id: I739edd6b4c58e19a8a16ddce863eea14ec933697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555005
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71384}
* Replace deprecated Factory::NewFunction* calls with JSFunctionBuilder.
* Drive-by: rename Factory::NewFunctionForTest to ..ForTesting (this is
the correct suffix recognized by our tooling to ensure it's only
called from tests).
Tbr: clemensb@chromium.org
Bug: v8:8888
Change-Id: I110063803e5b467bd91b75fe8fea2ca4174f2bcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529129
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71101}
Remove the duplicate utility function and use the base::Stack
equivalent instead which provides more stack utilitiy functionality.
Change-Id: Ia7a79f2530b64ceb6e2ce33445c876980b4b2a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509595
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70930}
Fix super calls so that arguments are evaluated before the
super constructor is checked to be in fact a constructor.
A new bytecode is introduced to split the IsConstructor check
out from the current GetSuperConstructor bytecode.
Bug: v8:10111
Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70881}
Implements https://github.com/tc39/ecma262/pull/2154, which allows
module export names to be string literals.
Semantics highlights:
- It is a SyntaxError for string literal export names to have unpaired
UTF16 surrogates.
- It is a SyntaxError for string literal export names to be used as
the local name without being followed by a 'from' clause. For example,
`export { "foo" }` and `export { "foo" as "bar" }` are errors, but
`export { "foo" } from "./module.js"` is allowed.
The remaining failing test262 test is wrong:
https://github.com/tc39/test262/issues/2866
Bug: v8:10964
Change-Id: Ib3e06e1ee6b3f1b60ed7f24e21902e17ddfc0351
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482335
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70692}
Parse the AssertEntries in an import assertion clause, storing them in
a map. Plumb them through the parser to the appropriate
SourceTextModuleDescriptor methods.
The next change will plumb them into the SourceTextModuleDescriptor's
ModuleRequestMap and through to SourceTextModuleInfo::New.
Bug: v8:10958
Change-Id: I19c31090520f14f94d014e760f5fe372bf773fc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482326
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70622}
We can use tag dispatching to distinguish between the synchronized and
non-synchronized accessors. Also eliminated the need of adding explicit
"synchronized" in the name when using the macros.
As a note, we currently have one case of using both relaxed and
synchronized accessors (Map::instance_descriptors).
Cleaned up:
* BytecodeArray::source_position_table
* Code::code_data_container
* Code::source_position_table
* FunctionTemplateInfo::call_code
* Map::instance_descriptors
* Map::layout_descriptor
* SharedFunctionInfo::function_data
Bug: v8:7790
Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70306}
Sorting a TypedArray with a custom compare function requires us to
copy the array's contents to a FixedArray. When the TypedArray is
larger than FixedArray::kMaxLength, we should throw a RangeError
rather than crashing with an OOM message.
Fixed: v8:10931
Change-Id: I8a27cc0ac80a9172bc5e8e154fdf4ccce5974317
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440575
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70232}
This fixes the logic in the desugaring of destructuring assignments. In
particular, a spread element would not check if previous `next` results
had already been done, and would always call `next()` again.
Change-Id: I1bd384678722e6cf51c5777fc3b0dd965360291a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2430488
Commit-Queue: Gus Caplan <snek@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70144}
During spread operation, after VisitForAccumulatorValue,
set the position of the current expression again
Bug: chromium:929844
Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531
Commit-Queue: HyeockJin Kim <kherootz@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69677}
