This changes how we setup modules from being entirely bytecode based to a
single fixed array with metadata that's passed into a runtime function
DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
replace the bytecode that calls those functions with explicit calls before we
even start running the code. In the case of modules that will obviate the need
for modules to be generators.
Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66097}
This makes the code a little more specific to what's happening: There is only 1
global scope, and if there is one, we know its declarations are
info->scope()->declarations(). That means we don't need multiple
GlobalDeclarationsBuilders, and we don't need to cache partially serialized
versions of the declarations. One builder is enough, and we can simply walk
those declarations if there are any.
Additionally this CL drops unnecessary information passed into DeclareGlobals:
- Global functions always have the name on the shared function info, so we can
drop the name.
- Due to lazy feedback vectors there's no point in trying to preinitialize
global loads. Also this was only preinitializing global loads at the script
level, not sub functions; without even checking whether the global load was
used. It may actually have caused us to do more work and allocate more global
load feedback slots than neccessary.
Change-Id: Ibbdd029abe5a39ba27f7fc9be84670c5d444d98d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997123
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65725}
This reverts commit 91e3243d60.
Reason for revert: This deopts to the wrong point.
Original change's description:
> Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
>
> Current GetIterator bytecode loads and calls @@iterator property on a
> given object. This change extends the bytecode functionality to check
> whether the value returned after calling @@iterator property is a valid
> JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
> returned value is not a valid JSReceiver. This change absorbs the
> functionality of additional two bytecodes - JumpIfJSReceiver and
> CallRuntime, that are part of the iterator protocol in the GetIterator
> bytecode.
>
> Bug: v8:9489
> Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Cr-Commit-Position: refs/heads/master@{#63704}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9489
Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65541}
The current error message assumes all classes are named, which results
in a double space and awkward wording when calling an anonymous class
constructor.
Bug: v8:10025
Change-Id: Ibe913152c0816cbbaaa0c7a88db4e415762ae9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947336
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65354}
This patch implements inspector support for private instance methods:
- Previously to implement brand checking for instances with private
instance methods we store the brand both as the value with the brand
itself as the key in the stances. Now we make the value the context
associated with the class instead.
- To retrieve the private instance methods and accessors from the
instances at runtime, we look into the contexts stored with the
brands, and analyze the scope info to get the names as well as
context slot indices of them.
- This patch extends the `PrivatePropertyDescriptor` in the inspector
protocol to include optional `get` and `set` fields, and make the
`value` field optional (similar to `PropertyDescriptor`s).
Private fields or private instance methods are returned in the
`value` field while private accessors are returned in the `get`
and/or `set` field. Property previews for the instaces containing
private instance methods and accessors are also updated similarly,
although no additional protocol change is necessary since the
`PropertyPreview` type can already be used to display accessors.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:9839, v8:8330
Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65337}
This patch excludes brand symbols from the result of
JSReceiver::GetPrivateEntries so that the brands do not show up
when the instances are inspected from the DevTools (e.g. via
`Runtime.getProperties()`).
To implement this, we use a bit in the Symbols to denote whether
it's a brand symbol. A brand symbol is also a private name
symbol so that we can just reuse the IC for accessing private
names and do not need to jump through extra ORs.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:8671, v8:9839, v8:8330
Change-Id: I24346aeedce3602395289052d1e1350ae9390354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1909757
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#64899}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64888}
Currently if the argument to matchAll has a null or undefined .flags
property, the error message will read "String.prototype.matchAll called
on null or undefined", which is very confusing.
Drive-by fix: Remove the related and unused
MethodInvokedOnNullOrUndefined error.
Bug: v8:9895
Change-Id: I3644545282ac8d2156c7a51086e37a0ab7f97a78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874619
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64530}
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64477}
This is a reland of c48096d442
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64451}
This reverts commit c48096d442.
Reason for revert: Flaky bot failures (https://bugs.chromium.org/p/v8/issues/detail?id=9744#c9)
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9744
Change-Id: Ia58067b41f1eb5880a52b36ead754d7190ff7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871922
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64424}
This is a reland of c07c02e1c4
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I0749cc2d8f59940c25841736634a70047116d647
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64380}
This reverts commit c07c02e1c4.
Reason for revert: MSAN failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/29251
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
Change-Id: I98dee04ab4d3ae977053982ec884b738d2f6f623
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868611
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64373}
Context objects have an extension slot, which contains further
additional data that depends on the type of the context.
This CL removes the extension slot from contexts that don't need
them, hence reducing memory.
The following contexts will still have an extension slot: native,
module, await, block and with contexts. See objects/contexts.h for
what the slot is used for.
The following contexts will not have an extension slot anymore (they
were not used before): script, catch and builtin contexts.
Eval and function contexts only have the extension slot if they
contain a sloppy eval.
Bug: v8:9744
Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
Commit-Queue: Victor Gomes <victorgomes@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64372}
This is a reland of c7c47c68f2.
This makes TSAN happy in addition to:
Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.
Bug: v8:9860
Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64360}
This reverts commit c7c47c68f2.
Reason for revert: breaks TSAN
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738
Original change's description:
> Reland "[runtime] Move Context::native_context to the map"
>
> This is a reland of f05bae1e0d
>
> Previously I presumed that the context read from a frame in the profiler was
> a valid context. Turns out that on non-intel we're not guaranteed that the
> frame is properly set up. In the case we looked at, the profiler took a
> sample right before writing the frame marker indicating a builtin frame,
> causing the "context" pointer from that frame to be a bytecode array. Since
> we'll read random garbage on the stack as a possible context pointer, I made
> the code reading the native context from it a little more defensive.
>
> Bug: v8:9860
>
> Original change's description:
> > [runtime] Move Context::native_context to the map
> >
> > Remove the native context slot from contexts by making context maps
> > native-context-specific. Now we require 2 loads to go from a context to the
> > native context, but we have 1 field fewer to store when creating contexts.
> >
> > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64296}
>
> Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64314}
TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64316}
This is a reland of f05bae1e0d
Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.
Bug: v8:9860
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64314}
This reverts commit f05bae1e0d.
Reason for revert: broke arm sim debug
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64299}
Remove the native context slot from contexts by making context maps
native-context-specific. Now we require 2 loads to go from a context to the
native context, but we have 1 field fewer to store when creating contexts.
Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64296}
This patch implements https://github.com/tc39/proposal-class-fields/pull/269
and makes sure we always throw TypeError when there is invalid private
name access in computed property keys.
Before this patch, private name variables of private fields and methods
are initialized together with computed property keys in the order they
are declared. Accessing undefined private names in the computed property
keys thus fail silently.
After this patch, we initialize the private name variables of private
fields before we initialize the computed property keys, so that invalid
access to private fields in the computed keys can be checked in the IC.
We now also initialize the brand early, so that invalid access to private
methods or accessors in the computed keys throw TypeError during brand
checks - and since these accesses are guarded by brand checks, we can
create the private methods and accessors after the class is
defined, and merge the home object setting with the creation
of the closures.
Bug: v8:8330, v8:9611
Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64225}
This patch refactors the declaration and allocation of the class variable, and
implements static private methods:
- The class variable is declared in the class scope with an explicit
reference through class_scope->class_variable(). Anonymous classes
whose class variable may be accessed transitively through static
private method access use the dot string as the class name. Whether
the class variable is allocated depending on whether it is used.
Other references of the class variable in the ClassLiteral AST node
and the ClassInfo structure are removed in favor of the reference
through the class scope.
- Previously the class variable was always (stack- or context-)
allocated if the class is named. Now if the class variable is only
referenced by name, it's stack allocated. If it's used transitively
by access to static private methods, or may be used through eval,
it's context allocated. Therefore we now use 1 less context slots
in the class context if it's a named class without anyone referencing
it by name in inner scopes.
- Explicit access to static private methods or potential access to
static private methods through eval results in forced context
allocation of the class variables. In those cases, we save its index
in context locals in the ScopeInfo and deserialize it later, so that
we can check that the receiver of static private methods is the class
constructor at run time. This flag is recorded as
HasSavedClassVariableIndexField in the scope info.
- Classes that need the class variable to be saved due to
access to static private methods now save a
ShouldSaveClassVariableIndexField in the preparse data so that the
bits on the variables can be updated during a reparse. In the case
of anonymous classes that need the class variables to be saved,
we also re-declare the class variable after the reparse since
the inner functions are skipped and we need to rely on the preparse
data flags to remember declaring it.
Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
Bug: v8:8330
Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64219}
Adds support for parsing top level await to V8, as well as
many tests.
This is the final cl in the series to add support for top level
await to v8.
Spec is here:
https://tc39.es/proposal-top-level-await/#sec-execute-async-module
Bug: v8:9344
Change-Id: Ie8f17ad8c7c60d1f6996d134ae154416cc1f31e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1703878
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63946}
Current GetIterator bytecode loads and calls @@iterator property on a
given object. This change extends the bytecode functionality to check
whether the value returned after calling @@iterator property is a valid
JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
returned value is not a valid JSReceiver. This change absorbs the
functionality of additional two bytecodes - JumpIfJSReceiver and
CallRuntime, that are part of the iterator protocol in the GetIterator
bytecode.
Bug: v8:9489
Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63704}
This patch uses a bit in the Variable bit fields to distinguish
static private names from instance private names, so that we
can check the conflicts of private accessors that are complementary
but with different staticness in the parser, and use this
information later when generating code for checking static brands
for private method access.
Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
Bug: v8:8330
Change-Id: I8d70600e594e3d07f77ea519751b7ca2e0de87b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781010
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63677}
This is a reland of 8b89a7c32d
Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
1c8981e3f4).
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}
Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
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 is a reland of 1fba044154
Chromium expectation tests have been disabled, and will be enabled
Original change's description:
> [destructuring] Elide coercible check for simple keys
>
> Simple object destructuring, such as `let {a,b} = o`, is less efficient
> than the equivalent assignments `let a = o.a; let b = o.b`. This is
> because it does a nil check of `o` before the assignments. However, this
> nil check is not strictly necessary for simple (i.e. non-computed) names,
> as there will be an equivalent nil check on the first access to o in
> `o.a`. For computed names the computation is unfortunately obervable.
>
> So, we can elide the nil check when the first property (if any) of the
> destructuring target is a non-computed name. This messes a bit with our
> error messages, so we re-use the CallPrinter to also find destructuring
> assignment based errors, and fiddle with the error message there. As
> a side-effect, we also get out the object name in the AST, so we can
> output a slightly nicer error message.
>
> Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63453}
TBR=verwaest@chromium.org
Bug: chromium:999473
Change-Id: Ib0b2e4be433c50521ba1722e1c06b672bfefa405
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777702
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63477}
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 1fba044154.
Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347
Original change's description:
> [destructuring] Elide coercible check for simple keys
>
> Simple object destructuring, such as `let {a,b} = o`, is less efficient
> than the equivalent assignments `let a = o.a; let b = o.b`. This is
> because it does a nil check of `o` before the assignments. However, this
> nil check is not strictly necessary for simple (i.e. non-computed) names,
> as there will be an equivalent nil check on the first access to o in
> `o.a`. For computed names the computation is unfortunately obervable.
>
> So, we can elide the nil check when the first property (if any) of the
> destructuring target is a non-computed name. This messes a bit with our
> error messages, so we re-use the CallPrinter to also find destructuring
> assignment based errors, and fiddle with the error message there. As
> a side-effect, we also get out the object name in the AST, so we can
> output a slightly nicer error message.
>
> Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63453}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63465}
Simple object destructuring, such as `let {a,b} = o`, is less efficient
than the equivalent assignments `let a = o.a; let b = o.b`. This is
because it does a nil check of `o` before the assignments. However, this
nil check is not strictly necessary for simple (i.e. non-computed) names,
as there will be an equivalent nil check on the first access to o in
`o.a`. For computed names the computation is unfortunately obervable.
So, we can elide the nil check when the first property (if any) of the
destructuring target is a non-computed name. This messes a bit with our
error messages, so we re-use the CallPrinter to also find destructuring
assignment based errors, and fiddle with the error message there. As
a side-effect, we also get out the object name in the AST, so we can
output a slightly nicer error message.
Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63453}
Wrap the obj and method registers in BuildGetIterator in a register
allocation scope, so that they don't get materialised before the
JumpIfJSReceiver jump if they don't have to.
Bug: v8:9649
Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63393}
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}
This is the first in a series of changes to reduce the number of
bytecodes generated for the iteration protocol based operations.
The GetIterator bytecode introduced in this change currently loads the
@@iterator symbol from an object that was previously done using the
LdaNamedProperty bytecode. This change uses builtin-based mechanism
that would be extended to perform additional operations in the future
on absorbing the bytecodes associated with the GetIterator operation
from the iteration protocol.
Bug: v8:9489
Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63139}
Cleans up a plethora of JumpIfUndefined().JumpIfNull()
occurances by introducing a new JumpIfUndefinedOrNull
bytecode.
Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63130}
This patch stores the home objects in private methods that
access super properties.
Bug: v8:8330
Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63113}
Fix a cctest/test-bytecode-generator/PrivateMethods mismatch between the
PrivateMethods source string and the snippet in the golden file due to
missing newline at the end of the string. Change C++ raw string back to
a normal string since in this case it makes it harder to see the
problem.
Change-Id: I3bea8873d37fbacac65548be8261f6b04104132f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709413
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62823}
Perform a best-effort check for module context and provide an
appropriate error.
As seen from the import-blah-script.js test, we could have invalid
import expressions in a script context that could result in an error
saying "Cannot use import statement outside a module" which isn't
the ideal error because the error is an incorrect import
expression.
But, when the developer changes to a module context, the
correct error is thrown.
To fix this, we'd have to refactor and call ParseImportDeclaration,
and then throw an appropriate error, which seems like a lot of
overhead for not enough gain.
Bug: v8:9392, v8:6513
Change-Id: I520ebb490fff4d95743a7c751d4095db9a35d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675948
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62358}
This patch implements the access of private methods:
- When building property loads, check whether it requires
a brand check. If so, build the brand check and load the
property (the method) from the context instead.
- Throw type errors when there is an attempted write to private
methods.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: Ic917d2a0030196c1940b0c0ba65a340af736c769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1610383
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62292}
As per the new specs, when the exception is thrown by iterator's return method
while doing iterator close because it is not callable, the exception is
suppressed in the same way as if the return method is called and threw an exception.
https://github.com/tc39/ecma262/issues/1398
Bug: v8:9056
Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#62035}
Added null check when printing the brand with --print-ast.
Bug: chromium:961507, chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
Change-Id: I3bf465f70c27914c9ec19f3f59ae018b28c9a866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605521
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61459}
This reverts commit b9191bd355.
Reason for revert: Clusterfuzz bugs
BUG=chromium:961507,chromium:961508
Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
> context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
> constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}
TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61406}
Per 262, yield* for async generators is supposed to Await the input value.
#sec-generator-function-definitions-runtime-semantics-evaluation
Section 14.4.13, yield *, 7.c.iii.1
Bug: v8:9051
Change-Id: Ie1e829309fe78683a9ff0adf816208c2bf0bb524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1600508
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61390}
