This additionally optimizes ExpressionListToExpression in the parser to
allocate Nary if possible. This allows us to drop unnecessary intermediate
objects in the parser, and avoids all the work altogether in the preparser.
Change-Id: I4a7d0ec3a28624c94ed85959d291e54eb81ffce3
Reviewed-on: https://chromium-review.googlesource.com/c/1297952
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56943}
This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList
buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values
through it, which will add them to the end of the buffer. Once the list is
done, you can copy out the values to a real ZonePtrList. That way you do not
need to guess what the required size of the list is, and you get better cache
locality.
Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3
Reviewed-on: https://chromium-review.googlesource.com/c/1296458
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56939}
This patch merges ClassLiteralProperty::PUBLIC_FIELD and
ClassLiteralProperty::PRIVATE_FIELD into ClassLiteralProperty::FIELD,
and moves the visibility part into ClassLiteralProperty::is_private()
for the ease of adding new combinations in the future.
Bug: v8:8330
R=gsathya@chromium.org
Change-Id: I54f64d05bccb1867d9111e4c80158a6075406d80
Reviewed-on: https://chromium-review.googlesource.com/c/1291052
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#56910}
This also changes Consume to bypass the stackoverflow check. Otherwise the
following pattern wouldn't work:
if (peek() == expected) {
f()
}
f() {
Consume(expected);
}
since the call to f can cause the overflow.
Change-Id: If2fd3181ecdf1fd681f584b630e83e0af4e4bf9d
Reviewed-on: https://chromium-review.googlesource.com/c/1286684
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56782}
Store the bits of a small type into the lower bits
of a pointer type that are free due to alignment.
Furthermore, reordering of members to reduce size of some classes.
Change-Id: I3c619cb74053f64995ea7d0cb395e8edda604f18
Reviewed-on: https://chromium-review.googlesource.com/c/1273019
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56726}
Adds support for enqueuing parallel parse / compile tasks for eagerly
compiled IIFEs during parsing. If the --parallel-compile-tasks flag is
enabled, the parser will pre-parse eager top-level IIFEs and enqueue a
task on the compiler dispatcher to do the actual parsing / compilation
on a worker thread.
Currently we always enqueue the task, but we likely want to only
enqueue parallel tasks where the script has multiple IIFEs or a
substantial amount of top-level script code before the IIFE to avoid
the main thread having to immediately block on the parallel task. This
work will be done as a follow-up.
BUG=v8:8041
Change-Id: If68d7c374548cabd4ec32f1fb6752da7d6aaae6b
Reviewed-on: https://chromium-review.googlesource.com/c/1275354
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56593}
The primary purpose of this is to untangle a circular dependency
objects.h -> handles.h -> objects.h. Most compilation units only
need message-template.h, without the rest of messages.h.
Bonus: change the enum to an enum class for improved type safety.
Bug: v8:3770
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I8102c55197a450811de2588a68a08e7f99ea6b9e
Reviewed-on: https://chromium-review.googlesource.com/c/1272193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56583}
Now that the preparser doesn't track errors anymore, it also doesn't make sense
to prepare the message.
Change-Id: Ifc69e67f9220be69812257b0fc18b55097236dbd
Reviewed-on: https://chromium-review.googlesource.com/c/1275818
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56574}
This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).
In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.
This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.
Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.
Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
This is behind a new flag --harmony-namespace-exports.
Bug: v8:8101
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9c252b6de2b08223fcf3296340b78d721471bdb4
Reviewed-on: https://chromium-review.googlesource.com/c/1258004
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56550}
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.
We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.
In essence we now turn an async function like
```js
async function f(x) { return await bar(x); }
```
into something like this (in Parser and BytecodeGenerator respectively):
```
function f(x) {
.generator_object = %_AsyncFunctionEnter(.closure, this);
.promise = %AsyncFunctionCreatePromise();
try {
.tmp = await bar(x);
return %_AsyncFunctionResolve(.promise, .tmp);
} catch (e) {
return %_AsyncFunctionReject(.promise, e);
}
}
```
Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function
```js
async function f(x) { return await x; }
```
goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.
Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!
Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
Instead directly declare the parameters as they are "added to the list".
Change-Id: I3245b5834157eb9f443ceb5da47db231a237d673
Reviewed-on: https://chromium-review.googlesource.com/c/1270815
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56481}
This flag has been on by default for some time. Once
https://chromium-review.googlesource.com/c/v8/v8/+/1270578 lands we need it to
be able to find duplicate parameters (to be spec-compliant).
Change-Id: I222023d7cd955127d3ecca42283b37063e962c58
Reviewed-on: https://chromium-review.googlesource.com/c/1270581
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56468}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
The Parser desugaring didn't use the AsyncReturnStatement consistently
to return from async functions (aka resolve the .promise with the return
value and return the .promise from the async function). Instead the
Parser essentially had a copy of the BytecodeGenerator functionality.
This change unifies the handling of returns from async functions.
Bug: v8:7522, v8:8238
Change-Id: Ib00a60aee30d541b84835d9cc83e9937b7a39e26
Reviewed-on: https://chromium-review.googlesource.com/c/1269036
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56453}
It was shipped in Chrome 67.
Bug: v8:6791, v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I94d8f0aa18570452403a35dea270b18f155c970a
Reviewed-on: https://chromium-review.googlesource.com/1253604
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56310}
PreParser now does not longer track which kind of error occurred.
If we see an error we reparse with the parser and report the error.
Furthermore, this fixes tests in test-parsing.
Change-Id: I1860949fab4d65ff4a5a1b63796c7574494f9d50
Reviewed-on: https://chromium-review.googlesource.com/1231173
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56281}
The Parser inserts a temporary .promise variable to hold the outer
promise for async functions, but doesn't assign an actually visible
name to it. This change puts the name ".promise" on it (similar to
what we do for other special variables like .result), which makes it
easier to debug this (for V8 developers). It's not observable to
regular developers.
Bug: v8:7522, v8:8015
Change-Id: I388352ad931a49102cb5afe350314337a505a150
Reviewed-on: https://chromium-review.googlesource.com/1249106
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56276}
Before I gave the preparser its own zone this was the case. I somewhat
accidentally dropped it when I used set_zone instead; causing large regressions
for certain types of pages.
Bug: chromium:889086
Change-Id: Ib3cf1f926b5c65506c66a97981c4544dccb372aa
Reviewed-on: https://chromium-review.googlesource.com/1245767
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56243}
The previous clear mechanism would also unnecessarily allocate a preparser.
This fixes regressions introduced by
https://chromium-review.googlesource.com/c/v8/v8/+/1238614
Change-Id: Ia3eef371c80857f2cd6cdd5852c849fa7f8716fc
Reviewed-on: https://chromium-review.googlesource.com/1238918
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56171}
Simplify zone discarding for preparsed functions by simply giving the preparser
its own zone that we reset whenever we finish preparsing something.
Change-Id: I3135fbbcd6caefa4654b1ae2b2207377e51bee26
Reviewed-on: https://chromium-review.googlesource.com/1238614
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56146}
Rather than allocating one in the zone and swapping them on discardable zone
swap, we simply swap the zone in the inferrer and allow the stacks to grow in
the outer zone. The inner segments will be dropped anyway.
This also introduces a PreParserFuncNameInferrer that just has dummy
implementations. That way we can avoid checking whether fni_ is nullptr at
runtime.
Change-Id: I0ff41b16d31571fc4606fd46b705d80b423343eb
Reviewed-on: https://chromium-review.googlesource.com/1238573
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56132}
Makes for a nicer stack trace
Bug: v8:5367
Change-Id: I6d77907e08c2c4efc7a1b25016c7e83841c7c574
Reviewed-on: https://chromium-review.googlesource.com/1211444
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55736}
Adds support for zone allocated (off-heap) ConsumedPreParsingScopeData to
enable worker-thread access to PreParsingScopeData during parallel IIFE
compile tasks.
In order to avoid code-duplication, a templated
BaseConsumedPreParsingScopeData is added which implements the logic for
decoding the bytestream into scope data. Two implementations of this
base class are instantiated for each of the underlying serialized scope date:
- ZoneConsumedPreParsedScopeData for exposing ZonePreParsedScopeData
- OnHeapConsumedPreParsedScopeData for exposing on-heap PreParsedScopeData
The interface for each of these classes is the ConsumedPreParsingScopeData,
which exposes the methods required by the parser to deserialize the required
data.
As a side-cleanup, moved Ucs2CharLength and Utf8LengthHelper implementations
to cc file so that we don't get a linker error if one of them are unused by
the cc file including the header.
BUG=v8:8041
Change-Id: Id502312d32fe4a9ddb6f5d2d9d3e3a9d30b9b27d
Reviewed-on: https://chromium-review.googlesource.com/1199462
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55711}
With FLAG_preparser_scope_analysis enabled we now always track
unresolved variables in the preparser. Fix the logic for deciding on
the correct RCS tracing category to be based on what the preparser does.
Change-Id: If691d51e6a2c09e554e4d96c10c37060cc7cca96
Reviewed-on: https://chromium-review.googlesource.com/1193303
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55460}
This is a reland of 1e5b6d99f4
Original change's description:
> [RCS] Create thread local runtime call stats tables for worker threads
>
> Creating a runtime call stats table for each worker thread task is expensive.
> Instead we create a single table per thread, and use TLS to get the correct one
> when starting a worker thread task.
>
> In order to correctly initialize the parser, scanner and parse-info's runtime
> call stats fields, we move creation of the scanner and parser onto the
> background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
>
> Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
> Reviewed-on: https://chromium-review.googlesource.com/1187522
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55448}
TBR=verwaest@chromium.org
Change-Id: I7c2f48280651d7632d99ee22d86260c72bc16185
Reviewed-on: https://chromium-review.googlesource.com/1193463
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55456}
This reverts commit 1e5b6d99f4.
Reason for revert: Breaks an arm64 MSAN bot - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/22601
Original change's description:
> [RCS] Create thread local runtime call stats tables for worker threads
>
> Creating a runtime call stats table for each worker thread task is expensive.
> Instead we create a single table per thread, and use TLS to get the correct one
> when starting a worker thread task.
>
> In order to correctly initialize the parser, scanner and parse-info's runtime
> call stats fields, we move creation of the scanner and parser onto the
> background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
>
> Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
> Reviewed-on: https://chromium-review.googlesource.com/1187522
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55448}
TBR=rmcilroy@chromium.org,verwaest@chromium.org
Change-Id: If3f28e65667816b7ae05c5efcb2f463379bc582b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1193224
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55449}
Creating a runtime call stats table for each worker thread task is expensive.
Instead we create a single table per thread, and use TLS to get the correct one
when starting a worker thread task.
In order to correctly initialize the parser, scanner and parse-info's runtime
call stats fields, we move creation of the scanner and parser onto the
background tasks for BackgroundCompileTask and UnoptimizedCompilationJob.
Change-Id: I36064c7fb43290968620b1985cc02637b16f4232
Reviewed-on: https://chromium-review.googlesource.com/1187522
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55448}
This reverts the following 3 CLs:
Revert "[scanner] Templatize scan functions by encoding"
Revert "[asm] Remove invalid static cast of character stream"
Revert "[scanner] Prepare CharacterStreams for specializing scanner and parser by character type"
The original idea behind this work was to avoid copying, converting and
buffering characters to be scanned by specializing the scanner functions. The
additional benefit was for scanner functions to have a bigger window over the
input. Even though we can get a pretty nice speedup from having a larger
window, in practice this rarely helps. The cost is a larger binary.
Since we can't eagerly convert utf8 to utf16 due to memory overhead, we'd also
need to have a specialized version of the scanner just for utf8. That's pretty
complex, and likely won't be better than simply bulk converting and buffering
utf8 as utf16.
Change-Id: Ic3564683932a0097e3f9f51cd88f62c6ac879dcb
Reviewed-on: https://chromium-review.googlesource.com/1183190
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55258}
This way we can avoid reencoding everything to utf16 (buffered) and avoid the
overhead of needing to check the encoding for each character individually.
This may result in a minor asm.js scanning regression due to one-byte tokens
possibly being more common.
Change-Id: I90b51c256d56d4f4fa2d235d7e1e58fc01e43f31
Reviewed-on: https://chromium-review.googlesource.com/1172437
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55217}
In order to know which labels are valid continue targets, we must
track the labels that immediately prefix an iteration statement.
Also document some things that I had to figure out.
Bug: v8:8033
Change-Id: Ia8288fd0e553a547aa0f9d1b4381bb103325bc3a
Reviewed-on: https://chromium-review.googlesource.com/1172292
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55110}
This templatizes CharacterStream by char type, and makes them subclass ScannerStream.
Methods that are widely used by tests are marked virtual on ScannerStream and final on
CharacterStream<T> so the specialized scanner will know what to call. ParseInfo passes
around ScannerStream, but the scanner requires the explicit CharacterStream<T>. Since
AdvanceUntil is templatized by FunctionType, I couldn't mark that virtual; so instead
I adjusted those tests to operate directly on ucs2 (not utf8 since we'll drop that in
the future).
In the end no functionality was changed. Some calls became virtual in tests. This is
mainly just preparation.
Change-Id: I0b4def65d3eb8fa5c806027c7e9123a590ebbdb5
Reviewed-on: https://chromium-review.googlesource.com/1156690
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54848}
Replace most uses of ZoneList in the parser with ZoneChunkList, which is
more Zone allocation friendly. Includes rewriting some index-based loops
as iterator-based, since ZoneChunkList random access isn't constant
time.
Bug: v8:7754
Change-Id: I49052b8afb90a4f3bfbe4076c2f90505b598e47a
Reviewed-on: https://chromium-review.googlesource.com/1145382
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54631}
api.h: MAKE_TO_LOCAL funcs need the types to be available.
scope.h, func-name-inferrer.h, bigint.h, module.h: These were using inline
headers -> de-inlined.
BUG=v8:7754,v8:7490
Change-Id: Id072f537682fb867cd68d79ca95b06628780d01f
Reviewed-on: https://chromium-review.googlesource.com/1131175
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54414}
This is a preliminary step before changing the way we store zone pointers in the zones.
Bug: v8:7903, v8:7754
Change-Id: I1e1af1823766c888ee0f8fe190f205f5b7e21973
Reviewed-on: https://chromium-review.googlesource.com/1118887
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54193}
This reverts commit aafd5c52ab.
Reason for revert: Tentative revert for
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/24825https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20msvc/3242
Original change's description:
> [parser][log] Log script id during background compilation
>
> - Add separate script-create, script-reserve-id and script-details log events
> - Add log events for CompilationCache hits and puts
> - Simplify function event logging by only pass along the script id
> - Explicitly create Scripts in parse-processor.js on script events only
> - Create a temporary script id in the ParseInfo for use during background
> parsing and compilation
> - Clean up ParseInfo initialization to centralize creation and use of
> script ids
> - Allow creating Scripts with predefined script ids
>
> Bug: chromium:757467, chromium:850038
> Change-Id: I02dfd1d5725795b9fe0ea94ef57b287b934a1efe
> Reviewed-on: https://chromium-review.googlesource.com/1097131
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53978}
TBR=ulan@chromium.org,cbruni@chromium.org,gsathya@chromium.org,leszeks@chromium.org
Change-Id: I629f72f51d5e086e2b54658c1fdd18cec268aab2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:757467, chromium:850038
Reviewed-on: https://chromium-review.googlesource.com/1112538
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53984}
- Add separate script-create, script-reserve-id and script-details log events
- Add log events for CompilationCache hits and puts
- Simplify function event logging by only pass along the script id
- Explicitly create Scripts in parse-processor.js on script events only
- Create a temporary script id in the ParseInfo for use during background
parsing and compilation
- Clean up ParseInfo initialization to centralize creation and use of
script ids
- Allow creating Scripts with predefined script ids
Bug: chromium:757467, chromium:850038
Change-Id: I02dfd1d5725795b9fe0ea94ef57b287b934a1efe
Reviewed-on: https://chromium-review.googlesource.com/1097131
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53978}
Replace all but one Handle<T*>(T*) calls with ones that explicitly pass
in an Isolate.
Requires plumbing Isolate* through several Parser functions which
previously avoided it because of worries about accessing the heap off
the main thread. In all off-main-thread cases, isolate will be nullptr
and every such function asserts with:
DCHECK_EQ(parsing_on_main_thread_, isolate != nullptr);
Also deletes unused function ParseInfo::ReopenHandlesInNewHandleScope.
Bug: v8:7786
Change-Id: I3dd9c49dcde49fdbcb684ba73f47a30d00fc495e
Reviewed-on: https://chromium-review.googlesource.com/1087272
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53820}
Removes most[1] explicit calls to GetIsolate() in parsing/ by passing
it through calling function functions and implicit calls via the single
argument Handle constructor and handle function.
[1] One remains in preparsed-scope-data.cc:
data_->GetIsolate()->PushStackTraceAndDie()
Bug: v8:7786
Change-Id: I4c445995a73c19bdf4649b65487b7443d56ddd2a
Reviewed-on: https://chromium-review.googlesource.com/1085057
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53513}
New intstrumentation consists of:
- kAsyncFunctionSuspended when async function is suspended on await
(called on each await),
- kAsyncFunctionFinished when async function is finished.
Old instrumentation was based on reusing async function promise.
Using this promise produces couple side effects:
- for any promise instrumentation we first need to check if it is
special case for async function promise or not - it requires
expensive reading from promise object.
- we capture stack for async functions even if it does not contain
awaits.
- we do not properly cancel async task created for async function.
New intsrumntation resolved all these problems as well as provide
clear mapping between async task and generator which we can use later
to fetch scope information for async functions on pause.
R=dgozman@chromium.org,yangguo@chromium.org
Bug: v8:7078
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifdcec947d91e6e3d4d5f9029bc080a19b8e23d41
Reviewed-on: https://chromium-review.googlesource.com/1043096
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53445}
see crbug.com/841460 , we recently hit some build issues when using
Goma + jumbo builds because of a conflict on the definition of CONST,
v8 defines it in globals.h and including windows.h also defines it. It
should be possible to fix this by adding a bunch of #undef CONST but it
seems a little bit hacky and might not always work (this could only fix
the problem temporary if the jumbo merge limit changes and cause some
include files to get included in a different order).
Renaming the v8 definition of CONST to kConst, this follows the
style guide guidelines: "there is no reason to change old code to use
constant-style names, unless the old names are actually causing a
compile-time problem"
(https://google.github.io/styleguide/cppguide.html#Enumerator_Names)
I also had to turn the PropertyConstness enum into an enum class to
avoid some conflicts (both PropertyConstness and VariableMode define
kConst).
Bug: chromium:841460
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2b70b9095374e88a5ae364cc557b39f20a3ab60f
Reviewed-on: https://chromium-review.googlesource.com/1064197
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53413}
Currently, we context allocate all parameters for generators.
With this CL, we keep arguments on stack (unless they escape to inner
closure) and copy them between the stack and the generator's register
file on suspend/resume. This will save context allocation in most cases.
Note: There is an asymmetry between suspend and resume.
- Suspend copies arguments and registers to the generator.
- Resume copies only the registers from the generator, the arguments
are copied by the ResumeGenerator trampoline.
Bug: v8:5164
Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649
Reviewed-on: https://chromium-review.googlesource.com/1063712
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53327}
This reverts commit 2df5e7a7b6.
Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
Original change's description:
> [parser] Slice the source string where possible
>
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
>
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
>
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}
TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
When internalizing string literals (for quoted strings or property names),
try to create a sliced string of the source string rather than allocating
a copy of the bytes.
This will not work for string literals that contain escapes (e.g. unicode
escapes), and currently does not support two-byte strings.
Bug: chromium:818642
Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
Reviewed-on: https://chromium-review.googlesource.com/1010282
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52898}
This patch moves the desugaring from the parser to the bytecode
generator for super calls that have a spread at a non last position.
This allows us to have the post super() call behavior, such as
initializing instance fields in one place in VisitCallSuper.
Bug: v8:7642
Change-Id: I00a693beb7078a63282359c1121b66bb62c157c8
Reviewed-on: https://chromium-review.googlesource.com/1009907
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52596}
With this CL the name of an SFI is either stored directly on the SFI
itself (for uncompiled ones) or on the related ScopeInfo if present.
- Combine scope_info and name field on SFI into name_or_scope_info field
- Change the name of a couple of SFI accessors: name => Name,
has_shared_name => HasSharedName, set_name => SetName
- Add Runtime::kGetFunctionName due to more complex SFI name accessing
Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idcce158446c9447b92d9a15125d086952c6e0824
Reviewed-on: https://chromium-review.googlesource.com/964201
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52001}
- Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition
This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.
Doesn't touch tagged templates
[esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
Fixes an error where TemplateLiteral printing in --print-ast
would try to read an element beyond the length of a vector.
BUG=v8:7415, chromium:820596
R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
Reviewed-on: https://chromium-review.googlesource.com/958408
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51933}
This reverts commit 8ae19e08b1.
Reason for revert:
Speculative revert for layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22215
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original change's description:
> [esnext] re-implement template strings
>
> - Add a new bytecode for the ToString operation, replacing the old
> intrinsic call (currently does not collect type feedback).
> - Add a new AST node to represent TemplateLiterals, and avoid
> generating unnecessary ToString operations in some simple cases.
> - Use a single feedback slot for each string addition, because the
> type feedback should always be the same for each addition
>
> This seems to produce a very slight improvement on JSTests benchmarks
> and bench-ruben.js from v8:7415, and it's possible that type feedback
> for the ToString bytecode could provide more opportunities to eliminate
> the runtime call in TurboFan.
>
> Doesn't touch tagged templates
>
> BUG=v8:7415
> R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
>
> Change-Id: If5a8c68558431f058db894d65776324abf54218e
> Reviewed-on: https://chromium-review.googlesource.com/945408
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Cr-Commit-Position: refs/heads/master@{#51853}
TBR=rmcilroy@chromium.org,caitp@igalia.com,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id0529b065493ffc20c8f2b1abacc4c1484c3c046
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7415
Reviewed-on: https://chromium-review.googlesource.com/958163
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51862}
- Add a new bytecode for the ToString operation, replacing the old
intrinsic call (currently does not collect type feedback).
- Add a new AST node to represent TemplateLiterals, and avoid
generating unnecessary ToString operations in some simple cases.
- Use a single feedback slot for each string addition, because the
type feedback should always be the same for each addition
This seems to produce a very slight improvement on JSTests benchmarks
and bench-ruben.js from v8:7415, and it's possible that type feedback
for the ToString bytecode could provide more opportunities to eliminate
the runtime call in TurboFan.
Doesn't touch tagged templates
BUG=v8:7415
R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
Change-Id: If5a8c68558431f058db894d65776324abf54218e
Reviewed-on: https://chromium-review.googlesource.com/945408
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51853}
This reverts commit 93fc3841c3.
Reason for revert: may break node.js integration
Original change's description:
> [parsing] inline ArrayLiteral creation for spread calls
>
> Instead of using runtime calls to generate the Array Literal passed to
> %reflect_call / %reflect_construct, we create an ArrayLiteral from the
> list of arguments, and perform spreads using the interpreter mechanism for
> spreading in ArrayLiterals (thus, the spreading becomes inline). This
> array literal is still passed to %reflect_call / %reflect_construct as
> before.
>
> This cuts the runtime for bench-spread-call.js -> testSpread roughly in
> half, and will likely improve further once
> https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
>
> BUG=v8:7446
> R=neis@chromium.org, adamk@chromium.org
>
> Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
> Reviewed-on: https://chromium-review.googlesource.com/939587
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51678}
TBR=adamk@chromium.org,neis@chromium.org,caitp@igalia.com,bmeurer@chromium.org
Change-Id: I4730077591bce0e5e7b2ce7d59678e8b7135cc08
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7446
Reviewed-on: https://chromium-review.googlesource.com/945769
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51682}
Instead of using runtime calls to generate the Array Literal passed to
%reflect_call / %reflect_construct, we create an ArrayLiteral from the
list of arguments, and perform spreads using the interpreter mechanism for
spreading in ArrayLiterals (thus, the spreading becomes inline). This
array literal is still passed to %reflect_call / %reflect_construct as
before.
This cuts the runtime for bench-spread-call.js -> testSpread roughly in
half, and will likely improve further once
https://chromium-review.googlesource.com/c/v8/v8/+/915364 has landed.
BUG=v8:7446
R=neis@chromium.org, adamk@chromium.org
Change-Id: I74a6acd3a60aad422e4ac575275c7b567659d8ad
Reviewed-on: https://chromium-review.googlesource.com/939587
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51678}
Avoid generating ADDs when concatenating the empty string with other
template parts. This prevents the creation of useless feedback slots,
and reduces the number of extra dispatches.
The impact on performance is negligible.
BUG=v8:7415
Change-Id: I7ef3806b53f7252f3a86f7007ae7050ac697c1e3
Reviewed-on: https://chromium-review.googlesource.com/938145
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#51669}
This proposal has not moved beyoned stage 2 in two years, and has never
moved past the HARMONY_INPROGRESS state in flag-definitions.h.
It was originally added to aide in desugaring yield*, but is no longer
used for that purpose.
Bug: v8:4700, v8:7310
Change-Id: Ieca40d8e4bf565516bbe71e47b996daa70d2e835
Reviewed-on: https://chromium-review.googlesource.com/935297
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51582}
Bug: v8:5368
Change-Id: I7c4f9101837a0bf4917bbb0c2f09587118168a02
Reviewed-on: https://chromium-review.googlesource.com/923362
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51449}
We don't use parser caches anymore and request code caches
explicitly using ScriptCompiler::CreateCodeCache. Hence
removing the support for both parser cache and code cache options.
They are still retained in CompileOptions for backwards
compatibility. Apart from the api.cc, no other part should see
this option.
Bug: chromium:779254, chromium:783124
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic8ad9afe3fa44bbb5adc71bdde59c0b4057a523d
Reviewed-on: https://chromium-review.googlesource.com/916261
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51416}
After f1a551800f, we no longer have to
deal with a case where we rewrite destructuring assignments belonging
to some inner function. Remove a bit of code and add DCHECKs to reflect
that fact.
Change-Id: I7553e86d4ae2f6290853eee38f85d2f243b778a9
Reviewed-on: https://chromium-review.googlesource.com/922893
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51404}
Previously, eval caching was only disabled if the root eval body code
contained a tagged template. Per discussion on
https://github.com/tc39/ecma262/pull/890, this is incorrect.
This change tracks if eval caching is allowed during parsing, and
uses this information to decide to insert
new entries into the cache, or not.
This change also removes the TemplateObject feedback kind, as it's no
longer needed (behaves the same as Literal feedback).
BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org
Change-Id: Ib75abe9159baf4d8ad10f8de99d2152714bd0094
Reviewed-on: https://chromium-review.googlesource.com/916945
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51373}
This doesn't enable the warning yet, but adds V8_FALLTHROUGH annotations
in enough places so that v8 can build with the warning on on my linux box.
Found one real bug
(in effect-control-linearizer.cc,
https://chromium-review.googlesource.com/c/v8/v8/+/850392/3/src/compiler/effect-control-linearizer.cc#825
).
Bug: chromium:812686
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3542550b9c24b545641d0f0fc43f28f2780b0ab3
Reviewed-on: https://chromium-review.googlesource.com/911731
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51322}
This introduces dedicated builtins
- FulfillPromise,
- RejectPromise, and
- ResolvePromise,
which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.
The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.
On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.
In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.
Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.
Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
which has been ratified and pulled into the specification. In particular,
template callsite objects are no longer kept in a global, eternal Map, but
are instead associated with their callsite, which can be collected. This
prevents a memory leak incurred by TaggedTemplate calls.
Changes, summarized:
- Remove the TemplateMap and TemplateMapShape objects, instead caching
template objects in the feedback vector.
- Remove the `hash` member of TemplateObjectDescriptor, and the Equals
method (used by TemplateMap)
- Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
that a new feedback vector is always created for eval() containing tagged
templates, even when the CompilationCache is used.
- GetTemplateObject bytecode now takes a feedback index, and only calls
into the runtime if the feedback is Smi::kZero (uninitialized).
BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
Reviewed-on: https://chromium-review.googlesource.com/624564
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51248}
Declare the private field variable in the preparser as well, to be
consistent with the parser.
Bug: v8:5386
Change-Id: I961ddf14e47b99701e2463cab0f4d4de140e1e3a
Reviewed-on: https://chromium-review.googlesource.com/905843
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51154}
Bug: v8:7387
Change-Id: I831bf8f580d4112d7e0f48d90bbe2f44eff73225
Reviewed-on: https://chromium-review.googlesource.com/897326
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51047}
Things that don't work yet:
(a) pre parsed scope data is broken
(b) private fields can be accessed outside classes
(c) no early or runtime error for accessing unknown fields
Things that do work:
everything else
Change-Id: I3d58be44e2be73ec50defb42403112a8a5e68c54
Bug: v8:5368
Reviewed-on: https://chromium-review.googlesource.com/865497
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50935}
Instead of building suspend_ids in the AST numbering, collect suspend
counts in the parser and assigning suspend ids during bytecode
generation.
Bug: v8:7178
Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0
Reviewed-on: https://chromium-review.googlesource.com/817598
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50830}
This patch does not add any functionality, it just parses the private
fields. Adds a new harmony flag as well.
Bug: v8:5368
Change-Id: I71ce11868f458571eb57a4bc922223931ce5baa8
Reviewed-on: https://chromium-review.googlesource.com/862526
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50662}
It was shipped in Chrome 63.
Bug: v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666
Reviewed-on: https://chromium-review.googlesource.com/858381
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50558}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.orgTBR=neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
Reviewed-on: https://chromium-review.googlesource.com/857593
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50518}
This reverts commit bf4cc9ee15.
Reason for revert: Breaks windows with msvc and linux with gcc
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
Original change's description:
> [esnext] load `iterator.next` only once at beginning of iteration
>
> https://github.com/tc39/ecma262/pull/988 gained concensus during the
> september 2017 TC39 meetings. This moves the load of the "next" method
> to the very beginning of the iteration protocol, rather than during
> each iteration step.
>
> This impacts:
>
> - yield*
> - for-of loops
> - spread arguments
> - array spreads
>
> In the v8 implementation, this also affects async iteration versions of
> these things (the sole exception being the Async-From-Sync iterator,
> which requires a few more changes to work with this, likely done in a
> followup patch).
>
> This change introduces a new AST node, ResolvedProperty, which can be used
> as a callee by Call nodes to produce the same bytecode as Property calls,
> without observably re-loading the property. This is used in several
> AST-desugarings involving the iteration protocol.
>
> BUG=v8:6861, v8:5699
> R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
> Reviewed-on: https://chromium-review.googlesource.com/687997
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50452}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6861, v8:5699
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/857616
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50454}
https://github.com/tc39/ecma262/pull/988 gained concensus during the
september 2017 TC39 meetings. This moves the load of the "next" method
to the very beginning of the iteration protocol, rather than during
each iteration step.
This impacts:
- yield*
- for-of loops
- spread arguments
- array spreads
In the v8 implementation, this also affects async iteration versions of
these things (the sole exception being the Async-From-Sync iterator,
which requires a few more changes to work with this, likely done in a
followup patch).
This change introduces a new AST node, ResolvedProperty, which can be used
as a callee by Call nodes to produce the same bytecode as Property calls,
without observably re-loading the property. This is used in several
AST-desugarings involving the iteration protocol.
BUG=v8:6861, v8:5699
R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
Reviewed-on: https://chromium-review.googlesource.com/687997
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50452}
This is just a rebased version of
https://chromium-review.googlesource.com/c/v8/v8/+/571453 with
no functional changes
Bug: v8:6889
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ia082cc09ca527505b288ac88e68e0b74eae94765
Reviewed-on: https://chromium-review.googlesource.com/849423
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50417}
Create a new function kind for initializer functions and ban arguments
if used in such a function.
Bug: v8:5367, v8:7183
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id3089e587b3d6a25f27224045f250e032b831818
Reviewed-on: https://chromium-review.googlesource.com/850547
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50369}
This patch implements https://github.com/tc39/proposal-class-fields/pull/65
and https://github.com/tc39/proposal-static-class-features/ by
splitting out instance and static field declarations into separate
flags for the separate proposals. Instance class fields is currently
at Stage 3 whereas static class fields is currently at Stage 2.
Bug: v8:5367
Change-Id: I133c945fd0b22dc5718c7bb61b10f22348087acd
Reviewed-on: https://chromium-review.googlesource.com/839778
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50293}
This changes the implementation of
v8::ScriptCompiler::CompileFunctionInContext
See design doc: https://goo.gl/ppkK6QR=adamk@chromium.org, marja@chromium.org, mstarzinger@chromium.org
Bug: v8:7172, chromium:70895
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iab0b6e879c1a3b33b623bfa2af9c706643c06fa7
Reviewed-on: https://chromium-review.googlesource.com/810946
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50148}
This gets rid of all the RewriteNonPattern gunk in the parser and
expression classifier, and removes one use of RewritableExpression.
This borrows pieces from several other CLs of mine which are currently
open, and includes a new and modernized abstraction for dealing with
iterators in BytecodeGenerator (so, this CL adds that, moves code from
BuildGetIterator around, and makes some minor changes to yield* which
should maintain compatability with the old behaviour).
This also implements a portion of the changes to the iteration protocol
(implemented fully in
https://chromium-review.googlesource.com/c/v8/v8/+/687997), but only for
the spread operator in Array Literals (the rest will follow).
BUG=v8:5940, v8:3018
R=rmcilroy@chromium.org, marja@chromium.org, adamk@chromium.orgTBR=adamk@chromium.org
Change-Id: Ifc494d663d8e46066a439c3541c33f0243726234
Reviewed-on: https://chromium-review.googlesource.com/804396
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50138}
This is a reland of c3bd741efd
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.orgTBR=kozyatinskiy@chromium.org
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Bug: chromium:791334
Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
Reviewed-on: https://chromium-review.googlesource.com/822341
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50045}
This reverts commit c3bd741efd.
Reason for revert: Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
Original change's description:
> Fix "this" value in lazily-parsed module functions.
>
> When preparsing top-level functions in a module, we didn't track
> unresolved variables. Consequently, "this" ended up referencing
> the global "this", which has the wrong value (in a module "this"
> is supposed to be the undefined value).
>
> This patch fixes that. This also lets us stop forcing context
> allocation of all variables in module scopes, which the patch
> takes care of as well.
>
> Bug: chromium:791334
> Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
> Reviewed-on: https://chromium-review.googlesource.com/808938
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50025}
TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:791334
Reviewed-on: https://chromium-review.googlesource.com/822258
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50036}
When preparsing top-level functions in a module, we didn't track
unresolved variables. Consequently, "this" ended up referencing
the global "this", which has the wrong value (in a module "this"
is supposed to be the undefined value).
This patch fixes that. This also lets us stop forcing context
allocation of all variables in module scopes, which the patch
takes care of as well.
Bug: chromium:791334
Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
Reviewed-on: https://chromium-review.googlesource.com/808938
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50025}
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
Currently RuntimeCallStats stores CounterIds as inner pointers.
This patch replaces them with enums and removes static table.
Bug: chromium:758183
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icb4030fc3ad3dd02e9c2648ce7c43b6f2d47fa9d
Reviewed-on: https://chromium-review.googlesource.com/796477
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49743}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
It was shipped in Chrome 62.
Bug: v8:5546, v8:4829
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3ac318639f1f7483d4d4f4fe5606387a856be98a
Reviewed-on: https://chromium-review.googlesource.com/777940
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49687}
Change the existing uses of the harmony-class-fields flag to
harmony-public-fields so that we can stage this separately
from the upcoming harmony-private-fields to get some
clusterfuzz coverage.
Bug: v8:5367
Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a
Reviewed-on: https://chromium-review.googlesource.com/792940
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49661}
Besides avoiding the weird hack of inserting a statement at the 0th
index of the function body, we also avoid allocating (and initializing)
the variable if it's unreferenced (which I'd wager is the common case).
Bug: v8:6092
Change-Id: If917d422bb4818cf21e8272aa786ca84d4472802
Reviewed-on: https://chromium-review.googlesource.com/784092
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49646}
Previously we only created synthetic variables in the parser and not
in the preparser, causing mismatch in the preparsed scope data.
This patch creates the variables in both parsers.
Bug: v8:5367
Change-Id: I9c511d0b9212bd36816956b06dc204b0b5920e1c
Reviewed-on: https://chromium-review.googlesource.com/789848
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49637}
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:
- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.
- This synthetic variable could potentially resolve to an initializer
of an outer class.
For ex:
class X extends Object {
c = 1;
constructor() {
var t = () => {
class P extends Object {
constructor() {
var t = () => { super(); };
t();
}
}
super();
}
t();
}
}
In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.
Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.
For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.
For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:
In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.
This is usually the common case and we don't pay any cost for not using
class fields.
(b) We are in a super() call inside an arrow function in the derived
constructor:
In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.
super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.
Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
This is a reland of 4d3bc552b5
Original change's description:
> [coverage] add coverage for binary expressions
>
> Adds block-level coverage tracking for binary && and ||
> expressions. Introduces a BinaryOperation source-range
> for tracking the operations themselves and an Expression
> source-range, used for tracking NaryLogical expressions.
>
> This builds on work by jgruber@chromium.org in
> the issue.
>
> TBR=marja@chromium.org
> R=jgruber@chromium.org, rmcilroy@chromium.org
>
> Bug: v8:6660
> Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18
> Reviewed-on: https://chromium-review.googlesource.com/754564
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49304}
Bug: v8:6660
Change-Id: I1c8571660d6c501d526886867bd841c49d5c44fd
Reviewed-on: https://chromium-review.googlesource.com/778288
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49613}
Adds some additional RCS counters to correctly account background
compilation to the background thread.
Also adds a ParseBackgroundProgram as a top-level event for background
parsing since otherwise only pre-parsing was being tracked.
Perf Sheriffs: Note this is likely to increase the Parse-Background
bucket in v8.runtime_stats benchmarks as it now accounts all background
parsing correclty.
BUG=v8:5203
Change-Id: I6ff614b725d85b0bc1901a7bf0e2bac8de1f7cff
Reviewed-on: https://chromium-review.googlesource.com/786237
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49603}
This moves the logging of the RCS event for background parsing tasks out
of the parser and performs it at the end of the background parsing task.
This is necessary in order to log background compile RCS events which happen
after parsing.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie216eeade0279d8243818a8eb59309969775823c
Reviewed-on: https://chromium-review.googlesource.com/776669
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49483}
Previously, we had lazy parsing of class constructor disabled when a
class literal had class fields because we were using a reference to
the initializer function variable to load the function and call it.
Instead, in this patch, we use the scope analysis to lookup this
initializer function variable.
Bug: v8:5367
Change-Id: Ib73d7e6abed33c04d1f574e7976bea4869d54757
Reviewed-on: https://chromium-review.googlesource.com/768384
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49406}
Previously, the Parser stored a Scope alongside a RewritableExpression
for each potential destructuring assignment. This Scope was later used
during rewriting to set the correct context for the rewriting. But this
approach failed if a new Scope was inserted into the Scope chain between
the time the assignment was parsed and when it was rewritten.
By storing the Scope directly in RewritableExpression,
ReparentExpressionScopes() is able to appropriately re-scope such
expressions prior to their rewriting.
Bug: chromium:779457
Change-Id: Ieb429a3da841f76d5798610af59da4fccb000652
Reviewed-on: https://chromium-review.googlesource.com/767666
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49368}
This partially retires --trace-parse and --trace-preparse which will be fully removed in
a later CL.
Drive-by-fix: make the Parser constructor arguments order more
consistent.
Bug: chromium:757467
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I80a688ce553adfa65ad346718604bd53a9e606a9
Reviewed-on: https://chromium-review.googlesource.com/744046
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49350}
Since each Array literal containing a spread is individually queued for
rewriting, there's no need for an AstVisitor here: a simple linear
pass through the queue is sufficient.
This patch deletes AstExpressionRewriter and all the machinery supporting
it in the AST. This code was built with the idea of using it as
a general expression rewriting mechanism in the parser, but those use
cases never materialized, and Array spread remains the only thing
that used this code.
Bug: v8:6092
Change-Id: I754c4883099e840881b005f20216f86e57721d5a
Reviewed-on: https://chromium-review.googlesource.com/765051
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49337}
Converts the ast prettyprinter to printing literals from the raw values
rather than internalized on-heap strings. This enables ast printing before
internalizing, and means we can avoid use of the isolate in the interpreter's
off-thread phase.
Also removes --print-builtin-ast and relies on just --print-ast to print
everything.
Finally, converts FunctionLiteral's debug_name function to return a
char[] which is created from the raw name literal where it exists, rather
than relying on the value having been internalized.
BUG=v8:5203
Change-Id: Ib69f754e254736f415db38713e6209465817e6f1
Reviewed-on: https://chromium-review.googlesource.com/758681
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49276}
The runtime_call_stats_ can be NULL on a worker thread when RCS
are enabled dynamically.
BUG=v8:7043
Change-Id: I1d26ae76c46955e017c82037b4a015ad86ba2f77
Reviewed-on: https://chromium-review.googlesource.com/755419
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49245}
Creates a new initializer function to instantiate instance class
fields in a base class.
An initializer function (similar to the one created for static fields)
is created during class declaration and assigned to a synthetic
context allocated variable.
This function is loaded from the variable during instantiation (when
the constructor is run) and run.
Bug: v8:5367
Change-Id: Ie11c2183b3001234ae41d7bcc2cb9b02c0764ab5
Reviewed-on: https://chromium-review.googlesource.com/754445
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49207}
Initialize the home object when we create the initializer function
keeping this in line with other functions that initialize home object.
Bug: v8:5367
Change-Id: I1c5e32ae0cb496740341e6c99c9359f6c5e00875
Reviewed-on: https://chromium-review.googlesource.com/754163
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49153}
This reverts commit c60934e9e4.
Reason for revert: breaks nosnap build
Original change's description:
> [Ast] Teach Ast Printer to print raw literal values.
>
> Converts the ast prettyprinter to printing literals from the raw values
> rather than internalized on-heap strings. This enables ast printing before
> internalizing, and means we can avoid use of the isolate in the interpreter's
> off-thread phase.
>
> Also removes --print-builtin-ast and relies on just --print-ast to print
> everything.
>
> Finally, converts FunctionLiteral's debug_name function to return a
> char[] which is created from the raw name literal where it exists, rather
> than relying on the value having been internalized.
>
> BUG=v8:5203
>
> Change-Id: I0e358d6acc9ae4516ed49e7a763e208fea5fcf66
> Reviewed-on: https://chromium-review.googlesource.com/749261
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49119}
TBR=rmcilroy@chromium.org,adamk@chromium.org
Change-Id: Ic9d511f5107666a2f6a2bf59d8e93643c32d4d2b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5203
Reviewed-on: https://chromium-review.googlesource.com/753627
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49120}
Converts the ast prettyprinter to printing literals from the raw values
rather than internalized on-heap strings. This enables ast printing before
internalizing, and means we can avoid use of the isolate in the interpreter's
off-thread phase.
Also removes --print-builtin-ast and relies on just --print-ast to print
everything.
Finally, converts FunctionLiteral's debug_name function to return a
char[] which is created from the raw name literal where it exists, rather
than relying on the value having been internalized.
BUG=v8:5203
Change-Id: I0e358d6acc9ae4516ed49e7a763e208fea5fcf66
Reviewed-on: https://chromium-review.googlesource.com/749261
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49119}
This patch evaluates computed properties in the order of declaration
during class definition time.
This patch creates a synthetic variable to store the result of
evaluating a computed property and then looks this up in the
initializer function.
Bug: v8:5367
Change-Id: I4182c6a01196d2538991818142890f6afb0e532b
Reviewed-on: https://chromium-review.googlesource.com/752567
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49115}
When closing untagged template string literals, create a single n-ary
addition operation, instead of a tree of binary operations.
As a clean-up, this also entirely removes the "second" field from n-ary
operations. This was proving to be too confusing an API when building
an n-ary operation incrementally from a single expression (rather than
converting a binary operation).
Bug: v8:6964
Change-Id: I8f2a395d413cf345bab0a1a347b47f412cde83b1
Reviewed-on: https://chromium-review.googlesource.com/739821
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49054}
Following up on adding n-ary nodes, this extends the parser and
interpreter to support n-ary logical operations.
Bug: v8:6964
Bug: chromium:731861
Change-Id: Ife2141c389b9abccd917ab2aaddf399c436ef777
Reviewed-on: https://chromium-review.googlesource.com/735497
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49029}
This eliminates the AstValue class, effectively moving its
implementation into the Literal AstNode. This should cause
no difference in behavior, but it does signal some shifts
in the underlying system. Biggest changes include:
- Reduction in AST memory usage
- No duplicate HeapNumbers in Ignition constant pools
- Non-String values are allocated either at constant pool
creation time (or at boilerplate creation time for literals),
rather than at AstValueFactory::Internalize() time.
There are a variety of test-only/debug-only changes due to these
switches as well.
Bug: v8:6984
Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
Reviewed-on: https://chromium-review.googlesource.com/731111
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49013}
Instead of creating a runtime call for the static class field
initializer in the AST, we do it in the bytecode generator.
This adds the initializer function to the ClassLiteral AST node.
Bug: v8:5367
Change-Id: Iffaa6531511023812011ee19fc96cea9e5c9d3f3
Reviewed-on: https://chromium-review.googlesource.com/736315
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49008}
This flag has been on by default since Chrome 61.
Bug: v8:5549
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I81c34d1d3a7dbd219acce2cdf0cf4917eb484002
Reviewed-on: https://chromium-review.googlesource.com/738312
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48945}
It's been on by default since Chrome 61.
Bug: v8:4806
Change-Id: I748d9008d29997667458649d7bf4999e15ff8615
Reviewed-on: https://chromium-review.googlesource.com/737416
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48943}
For the tagged case, we never use the Literal AST node, so don't bother
creating them in the first place. Instead, store AstRawStrings directly,
and only wrap with Literals when desugaring untagged templates into
binary ops.
This also makes the upcoming merge of Literal and AstValue simpler.
Bug: v8:6984
Change-Id: I9f12710b05c6d63d7e91f2707cd08093f7ff3f11
Reviewed-on: https://chromium-review.googlesource.com/736151
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48940}
Following up on adding n-ary nodes, this extends the parser to support
n-ary comma operations, including support for n-ary arrow function
parameters.
Bug: v8:6964
Bug: chromium:777302
Change-Id: Iba9c93b9eaa5a0870815b4fa29e84aa9d0c511e2
Reviewed-on: https://chromium-review.googlesource.com/735156
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48927}
Expressions of the form
a_0 + a_1 + a_2 + a_3 + ... + a_n
seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:
...
/
+
/ \
+ a_2
/ \
a_0 a_1
Traversing this tree during compilation can cause a stack overflow when n is
large.
Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form
n-ary +
/ | \
/ | ... \
a_0 a_1 a_n
The bytecode compiler can now iterate through the child expressions
rather than recursing.
This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.
Bug: v8:6964
Bug: chromium:724961
Bug: chromium:731861
Bug: chromium:752081
Bug: chromium:771653
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}
This removes all but one caller of Literal::raw_value(), thus
hiding AstValue from the rest of the codebase. This is in
preparation to move much of AstValue's implementation up
into Literal itself, thus avoiding the overhead of the
underling ZoneObjects and allowing us to remove complexity
such as the cache of Smi-valued AstValues.
Bug: v8:6984
Change-Id: I1b90aa64b9d26db36ef486afe73cda4473ef866e
Reviewed-on: https://chromium-review.googlesource.com/731109
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48884}
This is to enable it to also be used for reporting AsmJS errors such that
this can be moved off-thread.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia46040b14d010702f10c02b8254aea84cba4d54d
Reviewed-on: https://chromium-review.googlesource.com/735606
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48881}
This patch implements the runtime semantics of static public
class fields.
Adds a new InitializeClassFieldsStatement AST node that contains
all the static class fields and their initializers.
ClassLiteral is now desugared to be included in a do-exp that calls
an initializer function which contains this new AST node.
Bug: v8:5367
Change-Id: I3574e4c685f1c039de42521c122e24f8d28e5d6c
Reviewed-on: https://chromium-review.googlesource.com/714817
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48835}
The information that such functions must be parsed in module mode
didn't get properly propagated.
Also refactor some related code to make it more robust. In particular,
set parsing_module_ at parser construction time only.
Bug: v8:1569, v8:6919
Change-Id: Id136fb15c240373cad07c82025b778d0c0c43148
Reviewed-on: https://chromium-review.googlesource.com/716478
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48811}
Use an intrinsic for GetImportMetaObject and generate bytecode for the
case where import.meta has been initialized already. This way the
runtime method will only be called once per module.
Bug: v8:6693
Change-Id: If661e88e6accfb1c5795e37a80582d04f6dd87dd
Reviewed-on: https://chromium-review.googlesource.com/716536
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48801}
Inner functions which called eval, and were the kind of functions
that can use `super`, were erroneously not marked as "uses_super_property",
leading to downstream crashes when the runtime tried to load the
[[HomeObject]] from them.
This patch eliminates the public Scope::uses_super_property()
API and ensures that callers always call Scope::NeedsHomeObject()
instead.
This is a minimal fix designed for easy merging; it's likely that
in the long run we should remove most mentions of "uses super property"
and replace them with "needs home object" for clarity.
Bug: v8:5516, chromium:774994
Change-Id: Id269dd33e35bd40f6b59a3d3e19330687afa64f8
Reviewed-on: https://chromium-review.googlesource.com/721879
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48619}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=marja@chromium.org
Bug: v8:6837, v8:6921
Change-Id: I17cf5cbbac3d2992c3b3588cc66e8564982453b6
Reviewed-on: https://chromium-review.googlesource.com/681355
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48596}
Reuses the existing logic for BigInt.parseInt, adapted slightly
to allow octal and binary radix prefixes (and to support parsing
of a raw character buffer, rather than a v8::internal::String).
Bug: v8:6791
Change-Id: I41904b2204721eac452e0765fa9ff0ab26ee343b
Reviewed-on: https://chromium-review.googlesource.com/711334
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48560}
New code should use nullptr instead of NULL.
This patch updates existing use of NULL to nullptr where applicable,
making the code base more consistent.
BUG=v8:6928,v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c
Reviewed-on: https://chromium-review.googlesource.com/718338
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48557}
Previously, Function("++f`...`) would not throw an exception until the
created function was called. Now, it throws an early ReferenceError.
This change matches the behaviour in JavaScriptCore and SpiderMonkey.
Ordinary calls such as Function("++f()") are still thrown at runtime,
also compatible with JavaScriptCore and SpiderMonkey.
BUG=v8:4480, v8:6910
R=marja@chromium.org, littledan@chromium.org
Change-Id: If31c6d360a0464744eff5d8dd377ebff184ae00e
Reviewed-on: https://chromium-review.googlesource.com/712794
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48553}
This is a reland of ed6f00fb8e
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org
Bug: v8:6693
Change-Id: Ie2d746ad996a56ed6ff50b832f320fe44e02f231
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/712834
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48468}
This reverts commit ed6f00fb8e.
Reason for revert: tree is broken
NOTRY=true
NOTREECHECKS=true
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org,gsathya@chromium.org,jan.krems@groupon.com
Change-Id: I908a508d5db84cc8ae60d4fd4a0446bb570c1492
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/710760
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48434}
Rewrites references to import.meta to a new GetImportMetaObject runtime
call. Embedders can define a callback for creating the meta object using
v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
provided, an empty object with null prototype is created.
This adds an example implementation to d8 that sets meta.url.
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
Reviewed-on: https://chromium-review.googlesource.com/707902
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48433}
Rewrites import.meta expressions into null literals. Builds on top
of- and requires dynamic import parsing to simplify the implementation.
Adds a new --harmony-import-meta flag.
BUG=v8:6693
Change-Id: Iadb7ddf6bad8986bf3ad641dbd3826fe730b5f44
Reviewed-on: https://chromium-review.googlesource.com/702678
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48359}
The code used to rely on all such loops having a block scope around
them, but that is no longer the case for loops whose loop variables
are VAR-declared.
This patch introduces a new DeclarationDescriptor::Kind for such
variables, and sets it during parsing, allowing the variable
declaration code to note them as assigned appropriately.
Bug: chromium:768158
Change-Id: I0cd60e8c8c735681be9dbb9344a93156af09c952
Reviewed-on: https://chromium-review.googlesource.com/701624
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48320}
This reverts commit d0651bd108.
Reason for revert: Breaks gc stress with embedded snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355
Original change's description:
> [language] Implement optional catch binding proposal
>
> This allows the syntax `try {} catch {}` (with no binding after the
> `catch`).
>
> See https://github.com/michaelficarra/optional-catch-binding-proposal/
>
> Currently behind --harmony-optional-catch-binding.
>
> As part of the implementation, this allows TryCatchStatements to not
> have an associated catch scope; various paths which assumed they
> would have been updated to handle this case.
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
> Reviewed-on: https://chromium-review.googlesource.com/571453
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#48300}
TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com
Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/702334
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48303}
This allows the syntax `try {} catch {}` (with no binding after the
`catch`).
See https://github.com/michaelficarra/optional-catch-binding-proposal/
Currently behind --harmony-optional-catch-binding.
As part of the implementation, this allows TryCatchStatements to not
have an associated catch scope; various paths which assumed they
would have been updated to handle this case.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
Reviewed-on: https://chromium-review.googlesource.com/571453
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48300}
The context is the following proposal to make JSON a subset of
JavaScript: https://github.com/tc39/proposal-json-superset
There’s interest in performing a side investigation to answer the
question of what would happen if we stopped treating U+2028 and U+2029
as `LineTerminator`s *entirely*. (Note that this is separate from the
proposal, which just changes how these characters are handled in
ECMAScript strings.) This is technically a breaking change, and IMHO it
would be wonderful if we could get away with it, but no one really has
any data on whether or not we could. Adding this use counter lets us get
that data.
BUG=v8:6827
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
Reviewed-on: https://chromium-review.googlesource.com/693155
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48260}
- Add kProduceExhaustiveCodeCache to v8::ScriptCompiler::CompileOptions
to request eager compilation to add as much as possible to the code
cache for the script.
- Repurpose ParseInfo::kLazy flag.
- Remove ParseInfo::kDebug flag.
- Remove --serialize-toplevel as it has become obsolete.
R=marja@chromium.org
Bug: chromium:768705
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ife14f7a1d1c02e525f0b9dbfd2452013d67c7167
Reviewed-on: https://chromium-review.googlesource.com/684019
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48160}
Track whether the async arrow func parameter list was simple or not; the
information is already there, we just didn't pipe it through correctly. It's
needed by PreParser so that it can create the correct Scope structure.
Implementation notes:
- I could've used async_classifier for transmitting the "is_simple" bit, but I
made it explicit (it would be unnecessary to use ExpressionClassifier for
this, as we're not classifying any expressions) instead.
- I'm also moving work (setting parameter_list.is_simple) from Parser to
ParserBase, and adding a DCHECK in Parser to assert that the work was indeed
already done.
BUG=v8:5516,chromium:765532
Change-Id: Iacf91b150d1b57996544b5e64baa7d91ac134445
Reviewed-on: https://chromium-review.googlesource.com/674695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48132}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
Also store the variable directly on ClassLiteral, as the proxy serves
as a useless form of indirection.
Bug: v8:6092
Change-Id: If0182a808cde4e349c1bf5a003a1ecee5bd14b13
Reviewed-on: https://chromium-review.googlesource.com/667800
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48072}
This is in preparation for BigInt, since for BigInt operands the desugared
operations will no longer be equivalent.
Future CLs can move the handling of these operations further down the
pipeline; this is merely a start to get the Parser out of this business.
Bug: v8:6791
Change-Id: I9df89e03d3ca2bf627c75fc5efb10463c3ed8cf9
Reviewed-on: https://chromium-review.googlesource.com/653433
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47902}
This is a reland of 9b35364c51
Original change's description:
> [cleanup] Replace more instances of List with std::vector.
>
> Bug: v8:6333
> Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
> Reviewed-on: https://chromium-review.googlesource.com/651413
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47854}
Bug: v8:6333
Change-Id: I5d9482b061f26b57550a421ea4099372dc80767f
Reviewed-on: https://chromium-review.googlesource.com/654898
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47884}
What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.
Kudos & thanks to verwaest@ for a debugging session :)
BUG=chromium:761831
Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}
Bug: v8:6333
Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2
Reviewed-on: https://chromium-review.googlesource.com/651413
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47854}
This makes several changes to SwitchStatement handling:
- Store the CaseClause list inline (as it's always allocated)
- Only rewrite with additional blocks if the Block Scope for
the switch statement isn't empty
- Use Parser::IgnoreCompletion() instead of inserting an additional
`undefined` ExpressionStatement
Bug: v8:6092
Change-Id: Ib08d0ba851dd8e78b3dc74782b8e554541e79182
Reviewed-on: https://chromium-review.googlesource.com/644176
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47751}
There was only one case where this wasn't the case, having to do with
variable declarations, and for that case the information need not
actually be stored on the block, but should rather be propagated
to the VariableProxy.
Bug: v8:6092
Change-Id: I0d0025ec73d3dd4f9402606105d3e883a9417283
Reviewed-on: https://chromium-review.googlesource.com/639911
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47692}
The vast majority of callers pass null |labels| and kNoSourcePosition,
so make those the default arguments.
Bug: v8:6092
Change-Id: Ifac3f0d49f56b680ec75b1a7afde5e5e788d9cfd
Reviewed-on: https://chromium-review.googlesource.com/639761
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47691}
Also a few bits of related dead code in Parser.
Bug: v8:6092
Change-Id: Ie30aa1bd769b78fec2563fc6ba82ef0bcd7668bb
Reviewed-on: https://chromium-review.googlesource.com/639311
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47688}
This fixed a TODO from cec289ea by marking RewritableExpressions as
rewritten in AddArrowFunctionFormalParameters when decomposing
Assignments into pattern/initializer.
Also added a set_rewritten() helper method to RewritableExpression
to simplify callsites.
Change-Id: Ifa36c9fb6c79193cbbcb168eedf7f782dc73a77b
Reviewed-on: https://chromium-review.googlesource.com/622353
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47524}
Code aging is no longer supported by any remaining compilers now
that full codegen has been removed. This CL removes all vestiges of
code aging.
BUG=v8:6409
Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
Reviewed-on: https://chromium-review.googlesource.com/619153
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47501}
Instead of creating a new character stream to re-parse the asm.js module,
use the existing stream which was used by the parser. By doing this, we
avoid accessing the heap if the original character stream is a streaming
source or an external string, which will enable asm.js verification to run
off-thread in those situations.
BUG=v8:5203
Change-Id: I5dbf83c993512eb2f3dd709120e152e3f9900bdf
Reviewed-on: https://chromium-review.googlesource.com/616723
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47500}
Changes the contract of the parser to have a valid character stream passed
in the ParseInfo rather than the current situation where either:
- it is passed explicitly (e.g., for streaming scripts)
- a Script is passed and a character stream is created for this
- or a source and encoding is passed in ParseInfo and the character stream
is created from this.
The parse info also now owns the character stream (in a unique_ptr). It
can be destroyed using a new ResetCharacterStream() function. This will
enable the character stream to be kept live if any functions are asm.js
modules which were parsed, in order to be reused by the asm.js parser.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifda167391b2eadb38ebf9fcb2f565d2ed9ea3c6f
Reviewed-on: https://chromium-review.googlesource.com/616767
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47474}
Parse tasks are not currently used, and will need to be changed significantly
for background compilation, so we remove them for now.
BUG=v8:6093,v8:5203
Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745
Reviewed-on: https://chromium-review.googlesource.com/617140
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47446}
Currently, Declaration stores a Scope pointer to whichever Scope the
declaration appeared in. This is used to disallow var declarations
being hoisted over lexical declarations. For example:
{
let x;
{ var x; }
}
But in fact this is the only sort of case where storing the scope
is required: for lexical declarations (including function declarations
appearing in blocks), Declaration::scope() was always identical to
Declaration::proxy()->var()->scope(). That is, only var declarations
end up "nested" in this way.
This patch adds a subclass of VariableDeclaration to store the Scope.
Since the only thing that cares about that data is Scope analysis,
this isn't treated as a distinct AstNode::NodeType from VariableDeclaration,
leaving all AstVisitors untouched in the process.
Also reworked the logic in Scope::CheckConflictingVarDeclarations() for
clarity after making changes to accomodate the new code.
Change-Id: I6ee4298700508ab9e28a76ddb8504bae68bc473f
Reviewed-on: https://chromium-review.googlesource.com/619595
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47441}
The bug was that we didn't track using await as a class name inside
arrow function formal parameters, and hence didn't recognize the error
in this case:
async(x = class await {}) => {}
BUG=v8:6714
Change-Id: Iabe6c947a4f621fb72361671d77f4765ba1a9578
Reviewed-on: https://chromium-review.googlesource.com/616776
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47407}
Move the desugaring into BytecodeGenerator per TODOs.
BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org
Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}
This saves one pointer in Assignment for non-compound
assignment expressions.
Change-Id: I7ec32c1d378917c81ab55c42733b6af450ce65db
Reviewed-on: https://chromium-review.googlesource.com/612673
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47380}
This is a very minor cleanup noticed when reading this code. It's simply
a slight reduction in Parser/AST size.
Change-Id: Ice81253d1624723ef124a19442b0dcf4b77f4345
Reviewed-on: https://chromium-review.googlesource.com/614585
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47377}
This removes brittle Scope walking in FinalizeForOfStatement()
by making ParserBase call InitializeForEachStatement() while
in the proper Scope.
Bug: v8:6724
Change-Id: I6e828ccb3a5e4d98633a95a2bfb8d255ad0fc0eb
Reviewed-on: https://chromium-review.googlesource.com/614654
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47376}
This loop doesn't itself have a source position, so I wouldn't think
block coverage of it would make any sense (and all tests continue
to pass).
Removing this argument will make some refactoring I'm working on easier.
Bug: v8:6724
Change-Id: I4d6b734e077d9e61ad9362d07e57f155ec556221
Reviewed-on: https://chromium-review.googlesource.com/615385
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47375}
Makes ClusterFuzz start fuzzing with the flag on.
BUG=v8:5516
Change-Id: Ia80f7d22f12fe25efb226102a896e8b0e3537947
Reviewed-on: https://chromium-review.googlesource.com/610000
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47366}
PatternRewriter is an implementation detail of the Parser; as such,
there's no need for it to be exposed in parser.h (or even to most
of the Parser). This patch is a cleanup that hides all of PatternRewriter
in pattern-rewriter.cc, exposing only the few helper methods needed
by the rest of Parser in parser.h.
Also removed some duplication between the two PatternRewriter
initialization functions by adding a constructor, and added
a few DCHECKs here and there.
Change-Id: I1dbae8dc0172ff16e40585d0e718d206d2075b3a
Reviewed-on: https://chromium-review.googlesource.com/609365
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47291}
There are two reasons for Scopes to need information about eval calls
inside them:
- Eval in a scope, or any of its inner scopes, turns off a bunch of
scope analysis optimizations (e.g., all variables have to be treated
as "used" and context-allocated).
- Eval in a sloppy declaration scope means allows runtime addition
of var declarations.
This patch aims to make the code better-reflect this reality.
It's meant as a pure cleanup, with no expected change in behavior.
Change-Id: I744c5051bb7a90b11420930e9596e5d6c35eb440
Reviewed-on: https://chromium-review.googlesource.com/602848
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47257}
- Previous fix is https://chromium-review.googlesource.com/c/583531 but it
diverges Scopes created by PreParser from Scopes created by Parser.
- This CL creates the inner block scope a bit earlier and (temporarily) pushes
it into the scope chain for parsing the variable declarations in a for
loop. The previous approach was to first parse the variable declarations and
then reparent the AST nodes / Scopes created while parsing it afterwards.
- This CL partially reverts https://chromium-review.googlesource.com/c/583531;
the new fix only touches parser-base.h (diff between patch sets 2 and 3 is the
fix).
- The Ignition golden changes are basically undoing the changes done in that CL
too.
Bug: chromium:740591
Change-Id: Iceff1383ef066317e754942bb5ff0c70a91bc937
Reviewed-on: https://chromium-review.googlesource.com/603787
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47241}
This patch removes a few unnecessary bits of async function
parsing (the PrepareAsyncFunctionBody() helper method, the
FunctionBodyType enum) by doing separate handling of
block and single-expression async arrow functions.
Change-Id: I64f837635a23eaf06d42887ca7f9ac59c768f0f2
Reviewed-on: https://chromium-review.googlesource.com/601247
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47169}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.orgTBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
Change-Id: Idb6dfed1d0314c38c25b230faa7e28728cff2637
Reviewed-on: https://chromium-review.googlesource.com/587250
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47019}
This reverts commit 409f84c93b.
Reason for revert: Breaks nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288
Original change's description:
> [async-iteration] implement spec-change to `yield` in async generators
>
> Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
>
> AsyncGeneratorResolve no longer unwraps a value component. Instead, the
> value is unwrapped before the builtin call via Await, allowing Promise
> rejections to affect the generator control flow.
>
> Thus, all `yield <expr>` implicitly become `yield await <expr>`.
>
> Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
> the generator is resumed with `.return()`, the parameter passed to .return()
> is awaited before generator execution properly continues).
>
> BUG=v8:5855
> R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
> Reviewed-on: https://chromium-review.googlesource.com/523844
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47011}
TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com
Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5855
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593952
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47013}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the
value is unwrapped before the builtin call via Await, allowing Promise
rejections to affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
the generator is resumed with `.return()`, the parameter passed to .return()
is awaited before generator execution properly continues).
BUG=v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
Reviewed-on: https://chromium-review.googlesource.com/523844
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47011}
The yield* statement when used in combination with async iterators is not
supported yet, as that is desugared into a more complex construct that doesn't
offer a good dedicated bytecode to attach the source range information yet.
Note that invocation counts of generator functions are incorrect as they count
each resumption as an individual call. See https://crbug.com/v8/6594.
Bug: v8:6000
Change-Id: I7ac7073473c9b64bb207cdbc4dab083ec1145656
Reviewed-on: https://chromium-review.googlesource.com/582690
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46890}
Bug: chromium:740591
Change-Id: I869be41d8630b23704b9470c4d3db8a21bbde873
Reviewed-on: https://chromium-review.googlesource.com/583531
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46881}
Rather than using an ad-hock ownership model for ast_value_factory, use a
shared_ptr.
BUG=v8:5203
Change-Id: I5f2a573c8b175a3138ad8b01aa78bddadd16e6d3
Reviewed-on: https://chromium-review.googlesource.com/582628
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46874}
Removes the SharedFunctionInfo field from the ParseInfo structure. Instead
require a SharedFunctionInfo to be explicitly passed to ParseFunction.
Also renames GetUnoptimizedCode to CompileUnoptimizedFunction to make it
clear it should only be called for non-top-level code.
BUG=v8:5203
Change-Id: Ibce016e6a5290c3685f7f0a2f5fb1eb2df2ffc3b
Reviewed-on: https://chromium-review.googlesource.com/574589
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46814}
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.
As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:
- Modification of MacroAssembler AssertGeneratorObject. No longer
accepts a SuspendFlags parameter to determine which type of check to
perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
AccessBuilders associated with the [[await_input_or_debug_pos]] field
in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
prevent the need for the other SuspendFlag values.
BUG=v8:5855
TBR=bmeurer@chromium.org
Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
This includes several changes. From most to least interesting:
- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
first parameter (possible now that the CallRuntime invocation not
part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
palatable to avoid having `if (is_await())` in a number of
VisitSuspend functions.
BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.orgTBR=bmeurer@chromium.org
Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
Commit f37d726435 limited inner function
parsing to function declarations, to allow function expressions to
be eagerly-compiled if the parser discovered that they are immediately
invoked. But it's not only declarations that won't be immediately invoked:
methods and accessors are in the same boat, and should be treated the same.
This patch reverses the logic to exclude function expressions from inner
lazy treatment, thus making both function declarations and methods/accessors
inner-lazy-parseable.
Bug: v8:5501
Change-Id: I71a57667e52fcb917362ba629667c4c84ae29011
Reviewed-on: https://chromium-review.googlesource.com/569180
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46650}
This CL moves collected source range information out of AST nodes
and into a side table stored on ParseInfo. The side table is only
created if block coverage is enabled, so there's almost no memory
overhead in the standard case.
Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb
Reviewed-on: https://chromium-review.googlesource.com/566808
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46590}
Switch statements generate a counter for each clause plus a continuation
counter.
Bug: v8:6000
Change-Id: Ic55a7efda54de1152bd5283d753119aa2764afbd
Reviewed-on: https://chromium-review.googlesource.com/558249
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@{#46550}
This adds support for exception control flow by adding a counter behind throw
statements (never incremented), as well as a counter for catch and finally
blocks.
Bug: v8:6000
Change-Id: I3959772c889b543ab5e186ad7cd710e55a8aec23
Reviewed-on: https://chromium-review.googlesource.com/558993
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46476}
This way, each lazy function needs to handle only the data relevant to
itself. This reduced data handling overheads.
Other changes:
1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
function compilation is only done in the main thread.
2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:
- The data looks fundamentally different when we're producing it and when we're
consuming it.
- Cleanly separates the operations we can do in the "producing phase" and in the
"consuming phase".
Bug: v8:5516
Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
Reviewed-on: https://chromium-review.googlesource.com/528094
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46347}
Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL.
Bug: v8:6472
Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1
Reviewed-on: https://chromium-review.googlesource.com/539335
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46165}
let f = function g() { ... } declares "g" inside the function. This
CL makes the preparser declare it too, and saves + restores the scope data for
it.
BUG=v8:5516
Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b
Reviewed-on: https://chromium-review.googlesource.com/544816
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46133}
This method returns position of importing stmt in module source.
R=neis@chromium.org
Bug: chromium:721589
Change-Id: I8639796a001fdfec7cf5aa1bf1a27493f7a757a9
Reviewed-on: https://chromium-review.googlesource.com/541322
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46105}
The initial implementation did not work in certain cases.
For example, in the following case 'f' didn't have a shared name while
it should have had an empty shared name:
var f = (function() { return function() { return 42; } }();
The new implementation ensures that all anonymous functions have empty
shared name and if any of them happen to be an object literal property
value or an accessor function or a concise method then such a function
is marked as having no shared name.
Bug: v8:6459
Change-Id: I0f936afce0c152d91b2b41c1dc475a5ed841eca0
Reviewed-on: https://chromium-review.googlesource.com/538666
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46026}
Previously, when destructuring against null or undefined we would
print:
d8> var { x } = null
(d8):1: TypeError: Cannot match against 'undefined' or 'null'.
var { x } = null
^
TypeError: Cannot match against 'undefined' or 'null'.
at (d8):1:1
The above message uses the term "match" which isn't a common term in
JavaScript to describe destructuring. This message also doesn't
provide the name of the property that fails destructuring.
This patch changes the error message to be:
d8> var { x } = null;
(d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
var { x } = null;
^
TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
at (d8):1:1
This patch changes the message to say "destructure" instead of "match".
This patch adds support for printing property names that are string
literals. We iterate through every property and pick the first string
literal property name if it exists. This provides at least some
feedback to the developer.
This patch also makes the pointer point to the position of the
property name that fails destructuring.
For computed and numeric property names, we print a generic error:
d8> var { 1: x } = null
(d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
var { 1: x } = null
^
TypeError: Cannot destructure against 'undefined' or 'null'.
at (d8):1:1
Bug: v8:6499
Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
Reviewed-on: https://chromium-review.googlesource.com/537341
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45965}
This feature has been on by default without incident
since V8 5.8.
Bug: v8:5051
Change-Id: I1baf81922efd87e07448955147c50a5ba5a0aa42
Reviewed-on: https://chromium-review.googlesource.com/532214
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45881}
These accessors are only called from the Parser, never ParserBase, so
there's no need to expose them in parser-base.h. Instead, access them
through FunctionState::scope().
This also allows removal of the Types::Variable typedefs.
Bug: v8:6460
Change-Id: I01186c53d3cc2a2737f3c07169fdd122dff5b174
Reviewed-on: https://chromium-review.googlesource.com/530034
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45879}
Define compiler hints bits as bit fields but not as enum.
This eases adding new bit fields to the compiler hints field.
TBR=marja@chromium.org
Bug: v8:6470
Change-Id: Ia023bab25b925847924c45d5a57f85a14c8f1971
Reviewed-on: https://chromium-review.googlesource.com/529044
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45825}
ExpressionClassifier was used just for transmitting information back and forth
to DeclareFormalParameters.
As a bonus, we now do the Scope::IsDeclaredParameter check only when we're going
to use the information it produces.
BUG=v8:6092,v8:6474
Change-Id: Ib5ac6a779705caa74e933e1c6f03eaaf0f49bf05
Reviewed-on: https://chromium-review.googlesource.com/455836
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45809}
This adds block coverage support for simple iteration. For-of and
for-in loops are not yet covered, and we don't yet keep execution counts
for init, cond, and next statements.
BUG=v8:6000
Change-Id: I30b468a2c93f0bb60e857b6632be92920f6857e0
Reviewed-on: https://chromium-review.googlesource.com/527113
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45779}
Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
var o1 = { ''(){} };
var o1 = { [foo()](){} };
or
var o2 = { get ''(){} };
var o2 = { get [foo()](){} };
This is a preliminary step for using different layouts for closure objects with
and without computed names.
TBR=bmeurer@chromium.org, marja@chromium.org
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
The change also moves creation of the iterator result from the parser to the bytecode generator.
Unfortunately, async generators will stay on the old scheme (try-finally around generator body) because I am not exactly sure how they work.
Review-Url: https://codereview.chromium.org/2917263002
Cr-Commit-Position: refs/heads/master@{#45713}
Now that the BytecodeGenerator has a dedicated register holding
the generator object, BytecodeGenerator::VisitSuspend can
access the generator directly from that register. This reduces
by one the number of live registers at each suspend point.
Bug: v8:6351, v8:6460
Change-Id: I380a9d2bd8ca7eec6720e5392c1ca07dd0df0e2d
Reviewed-on: https://chromium-review.googlesource.com/522982
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45710}
In current implementation in expressions like await foo() we have break location right after foo call and before actual await.
And we additionally have a lot of other statement locations because of do scope.
Let's move async debugging closer to sync debugging and introduce only one break location for await - before awaited function call.
Bug: v8:6425,v8:6162
Change-Id: I7568767856022c49101e7f3b7e39a2e401d21644
Reviewed-on: https://chromium-review.googlesource.com/514046
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45625}
In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume.
The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change.
I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit.
Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish.
BUG=v8:6368
Review-Url: https://codereview.chromium.org/2898163002
Cr-Commit-Position: refs/heads/master@{#45515}
There are two break locations at the same source location by desugaring:
- call iterator.next,
- before variable assignment.
Additionally location for for..of loops is moved from before "of" to before each variable expression.
We should not report first implicit call to avoid user confusion. User still able to go into .next function with both scenarios:
- when this call is reached by stepOver or stepInto from previous line,
- when this call is reached because of breakpoint at current line.
BUG=v8:6425
R=dgozman@chromium.org,jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2893313002
Cr-Commit-Position: refs/heads/master@{#45509}
AstNodeFactory used to get the Zone directly from AstValueFactory. But that's
generally the wrong Zone (the main Zone, instead of the temp Zone), and the
creator of AstNodeFactory had to call set_zone right after. By adding a Zone
param, we can pass the correct Zone right away.
Also made PreParserFactory have an AstNodeFactory, so that we don't need to
create temporary AstNodeFactories all the time.
Also removed AstNodeFactory::BodyScope since DiscardableZoneScope essentially
did the same thing already.
BUG=v8:5516,v8:6092
Change-Id: I189d2e6afe91c91e49d8ed7e3496a0d9c405e1c5
Reviewed-on: https://chromium-review.googlesource.com/507129
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45370}
- Default constructor scopes won't need the scope data for deciding the scope
allocation of variables inside them. Also, PreParser doesn't construct them. So
they should be just skipped when applying the scope data.
- PreParser needs to declare the class name + have a proper end position for
the class scope.
- This makes all mjsunit tests pass with --experimental-preparser-scope-analysis.
- Also added several DCHECKs which were useful for debugging.
BUG=v8:5516
Change-Id: I5b3e6c60ed79efe25f33576a3547d707c700c6dd
Reviewed-on: https://chromium-review.googlesource.com/503208
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45303}
This lets us avoid allocating the "this" variable for every
generator, since the BytecodeGenerator can directly read
the receiver via BytecodeArrayBuilder::Receive() when passing
it into %_CreateJSGeneratorObject.
Bug: v8:6351
Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65
Reviewed-on: https://chromium-review.googlesource.com/500507
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#45281}
This removes logic tracking whether a number literal in the source
contained a "dot" character or not. The tracking was only needed for
validation of asm.js modules on the AST, it is obsolete now.
R=marja@chromium.org
Change-Id: Ib474e2281db80fe56d43e1af52221a7c66261e01
Reviewed-on: https://chromium-review.googlesource.com/503228
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45255}
As a first step towards improving generator creation, create a builtin
that can do it without a call to the runtime. Thread that builtin
into the interpreter via an intrinsic.
BUG=v8:6352
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2861983002
Cr-Commit-Position: refs/heads/master@{#45145}
Formal parameters of an arrow function are parsed even if the function
itself is preparsed. It is because we don't know if it is an arrow
function parameter list or just comma separated expression list.
When we parse:
(a, b = (function c() { return a; })())
call to function c may be just part of an assignment in an expression
list, but if it's followed by:
=> { return b; }
It is an arrow function and the call to c is a default parameter.
Before we see the arrow we might have already created a parse task
to parse function c.
BUG=v8:6093
Change-Id: I59a59acfdbbfd808dab1518060748be2addcd54a
Reviewed-on: https://chromium-review.googlesource.com/493347
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45132}
Removes the do-expression wrapping, modifies BytecodeGenerator change
to enter a class literal's block scope if needed.
This does not solve the actual bug in v8:6322, but helps mitigate it in
simple cases. The bug is caused by BytecodeGenerator not allocating a
large enough array of context registers to hold its entire stack,
allowing non-context registers to be overwritten during PushContext and
PopContext bytecodes.
Nevertheless, I like the idea of not depending on do-expressions when
possible, so I think it's worth doing anyways.
BUG=v8:6322
R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
Reviewed-on: https://chromium-review.googlesource.com/491074
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45110}
While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.
The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).
BUG=v8:6093
Change-Id: Ie6508211a04b90becfe44139cce1c8ecec386b6e
Reviewed-on: https://chromium-review.googlesource.com/486725
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45016}
With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
ObjectLiteral flags.
Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
This reverts commit 56a6fda316.
Reason for revert: Makes tsan flaky:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038
Original change's description:
> [parser] Inital parallel parse tasks implementation.
>
> While parsing top-level code eager functions are skipped just like lazy
> ones, but also a parse task is created for each.
>
> The parse tasks are run by the compiler dispatcher and can be executed
> either on background thread or in idle time.
> After parsing of top-level code finishes it waits for all unfinished
> parser tasks - possibly picking up and executing them on current thread.
> Afterwards parse task results are stitched together with top-level AST,
> in case of failures eager functions are treated just like lazy -
> parsing/compilation is retriggered for them in the runtime and proper
> errors are generated (performance is not optimized for error case at
> all).
>
> BUG=v8:6093
>
> Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
> Reviewed-on: https://chromium-review.googlesource.com/483439
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44849}
TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6093
Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd
Reviewed-on: https://chromium-review.googlesource.com/486883
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44859}
While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.
The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).
BUG=v8:6093
Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
Reviewed-on: https://chromium-review.googlesource.com/483439
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44849}
We collect function data for 2 purposes:
- Variable allocation data for lazy parsed functions which contain skippable functions.
- Data needed for creating FunctionLiterals for skippable functions.
In some cases, recompilation happens, and we need to make sure we're not trying
to skip a non-skippable function.
At the moment, we don't collect data for eagerly parsed scopes, since the
assumption is that they'll never get recompiled. (Fixing that will bigger design
changes.)
After this, we're down to 2 failures for mjsunit + --experimental-preparser-scope-analysis.
BUG=v8:5516
Change-Id: I704d488269f6d20a4b14596f2a0acc342ede32cb
Reviewed-on: https://chromium-review.googlesource.com/486802
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44848}
Preparser does not keep track of function names. If we want to
parse top-level function and top-level code was only preparsed
we need to parse the function name again. Even if we parsed the
function name, passing it is non-trivial so it makes sense to just
reparse.
BUG=v8:6093
Change-Id: Iafbcd677981f1db52b485eee0f0d769e4fd26543
Reviewed-on: https://chromium-review.googlesource.com/483359
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44742}
There's no reason to keep track, for a preparsed function itself,
whether that function calls eval. All that matters is that the ancestor
scopes are marked as having an inner scope which calls eval. The function
will have its "calls eval" bit persisted if/when it's fully parsed.
The only "behavioral" change in this patch is the removal of a DCHECK.
Bug: v8:6092
Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b
Reviewed-on: https://chromium-review.googlesource.com/481223
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44732}
The feature is not quite ready for getting ClusterFuzzed.
BUG=v8:5516
Change-Id: I90a42f950727c8ecf46cb2987c9a459b2ba1f5a7
Reviewed-on: https://chromium-review.googlesource.com/480400
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44693}
Moved recording data about functions to PreParser, since it knows the
num_inner_funcs. Recording used to be done in AnalyzePartially and then it was
too late, since at that point we only have the Scope and have lost all other
info about the function.
BUG=v8:5516
R=vogelheim@chromium.org
Change-Id: Icb379149882629f2181a1400781d31d653e300ba
Reviewed-on: https://chromium-review.googlesource.com/475833
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44682}
No usage sites are getting the length for uncompiled functions, so we can
postpone setting the correct length until after compilation. This way we don't
need to produce and store it for skipped inner functions.
In the current implementation, getting the function length compiles it (and
users rely on it - so the feature is probably not going to go away).
BUG=v8:5516
Change-Id: Id8c9a05d2391505a6cde613841094170c9a1b808
Reviewed-on: https://chromium-review.googlesource.com/468927
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44679}
e3246ad69c
removed some redundancies in yield and yield*.
In particular:
- AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL
- Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate
BUG=v8:6187, v8:5855
R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org
Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c
Reviewed-on: https://chromium-review.googlesource.com/471806
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44649}
Previously we didn't produce all data that we need for creating sensemaking
FunctionLiterals for the skipped functions.
Test in https://chromium-review.googlesource.com/c/457037 .
BUG=v8:5516
Change-Id: I1fd02c1109ef6e07e93da131062fd5101a8c8de9
Reviewed-on: https://chromium-review.googlesource.com/469767
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44515}
This is inital work in order to utilize CompilerDispatcher in parallel
parsing.
BUG=v8:6093
Change-Id: I6aae4f32ddb2314585d09039c1c5d7e658dc896f
Reviewed-on: https://chromium-review.googlesource.com/469709
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44509}
There's no need to set it so early - it's only needed when the function has
really been parsed. This way we don't need to produce and store it for skipped
inner functions.
BUG=v8:5516
Change-Id: Ibf59a8acb886ea3de9be140431a334a03b408f5b
Reviewed-on: https://chromium-review.googlesource.com/461827
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44410}
Remove destructuring assignments (parsed during arrow function formal
parameters) from queue for rewriting if parsing a lazy top-level arrow function.
Built ontop of https://chromium-review.googlesource.com/c/464769/
BUG=chromium:706234, chromium:706761, v8:6182
R=marja@chromium.org, adamk@chromium.org, vogelheim@chromium.org
Change-Id: Ib35196b907350d1d78e4c3fcbf4cc971bf200948
Reviewed-on: https://chromium-review.googlesource.com/465415
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44393}
Add the source position to variables if they are parameters.
Collect type information for parameters and return values.
Index the types by their corresponding source position. For the
types of return values, use the function end as source position.
Sample output for a function with 2 parameters (at source
position 252 and 258, and function end at 443)
*************
Function: testFunction
252:
Object
number
string
number
258:
undefined
boolean
undefined
undefined
443:
Object
number
string
number
*************
BUG=v8:5933
Change-Id: I3b8749afcac706c1834146abf1b5b4a3fd130fb6
Reviewed-on: https://chromium-review.googlesource.com/461919
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44299}
Rewrite returns in derived constructors to only replace undefined with
this, and otherwise just return the value, and let the construct stub
builtin throw an exception if the result is a primitive instead of a
JSReceiver.
R=yangguo@chromium.orgTBR=marja@chromium.org
BUG=chromium:706642
Review-Url: https://codereview.chromium.org/2788033002
Cr-Commit-Position: refs/heads/master@{#44288}
