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}
