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}
- Introduce new struct AsyncGeneratorRequest, which holds
information pertinent to resuming execution of an
AsyncGenerator, such as the Promise associated with the async
generator request. It is intended to be used as a singly
linked list, and holds a pointer to the next item in te queue.
- Introduce JSAsyncGeneratorObject (subclass of
JSGeneratorObject), which includes several new internal fields
(`queue` which contains a singly linked list of
AsyncGeneratorRequest objects, and `await_input` which
contains the sent value from an Await expression (This is
necessary to prevent function.sent (used by yield*) from
having the sent value observably overwritten during
execution).
- Modify SuspendGenerator to accept a set of Flags, which
indicate whether the suspend is for a Yield or Await, and
whether it takes place on an async generator or ES6
generator.
- Introduce interpreter intrinsics and TF intrinsic lowering for
accessing the await input of an async generator
- Modify the JSGeneratorStore operator to understand whether or
not it's suspending for a normal yield, or an AsyncGenerator
Await. This ensures appropriate registers are stored.
- Add versions of ResumeGeneratorTrampoline which store the
input value in a different field depending on wether it's an
AsyncGenerator Await resume, or an ordinary resume. Also modifies
whether debug code will assert that the generator object is a
JSGeneratorObject or a JSAsyncGeneratorObject depending on the
resume type.
BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.orgTBR=marja@chromium.org
Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
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: Ida2abd44b494030771b5663a8eb326edb0a53b72
Reviewed-on: https://chromium-review.googlesource.com/461160
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44235}
Introduce 'contextual keyword' tokens, which are parsed as identifiers but
in some contexts are treated by the parser like proper keywords. These are
usually keywords introduced by recent ECMAScript versions, which for reasons
of backwards compatibility are still permissible as regular identifiers in
most contexts.
Current usage is to check for Token::IDENTIFIER and then do a string
compare. With this change the initial scan will scan them as usual, but
will then record the token as IDENTIFIER plus a secondary token with the
'contextual' value.
BUG=v8:6902
Change-Id: I6ae390382998cf756a23720bd481cb9c0eb78a72
Reviewed-on: https://chromium-review.googlesource.com/459479
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44189}
As far as I can see, we have had this bug as long as destructuring assignments
have been there (i.e., this is not regression).
The problem was that Parser::DoParseFunction parsed the arrow function parameters
but didn't rewrite the destructuring assignments in them.
BUG=chromium:704811
Change-Id: I0b1424e7d5103eda6efd51b403fe81a4ee235e01
Reviewed-on: https://chromium-review.googlesource.com/459618
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44177}
Removes the AstString super-class and makes the two sub-classes stand-alone.
That also removes the slightly awkward implementation of a super-class with
dynamically dispatched behaviour, except it was manually implemented because
virtual function calls were considered expensive.
BUG=v8:6902
Change-Id: I079a2372557aa17ee839efcaddb9b7fe86e38b4d
Reviewed-on: https://chromium-review.googlesource.com/458428
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44104}
A step towards removing isolate from ParseInfo.
Removing isolate from ParseInfo will make it easier to create and
execute parse tasks on background threads.
BUG=v8:6093
Change-Id: If5e7ba2f76f9f8422c26f47c9f0eb5b197114b25
Reviewed-on: https://chromium-review.googlesource.com/458000
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44089}
It was removed so that Parser::DeserializeScopeChain does not have
to get it from ParseInfo.
Only a small step in direction of removing isolate from ParseInfo.
BUG=v8:6093
Change-Id: Iaaf92dc6eb5ec9c4efc05ac73666fbc66e0ed8c1
Reviewed-on: https://chromium-review.googlesource.com/457999
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44057}
While the primary use-case for Suspend nodes is the Yield expression,
there are other uses as well: Await expressions, and the initial suspend
of Generators, which returns an object matching the Iterator protocol.
"Suspend" is a better representation of the spec text (closer
to the spec text for the values of [[GeneratorState]] and
[[AsyncGeneratorState]]), and can make it easier to understand the
meaning of what I had previously called Yield::is_normal() (now
Suspend::is_yield()).
Changes requested as part of https://chromium-review.googlesource.com/c/447117/
BUG=
R=neis@chromium.org, adamk@chromium.orgTBR=bmeurer@chromium.org, paul.lind@imgtec.com, joransiu@ca.ibm.com, weiliang.lin@intel.com
Change-Id: Ic6f15b04fff091c20f26526391b967287c06f6bf
Reviewed-on: https://chromium-review.googlesource.com/455583
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44038}
Rebase of https://chromium-review.googlesource.com/446336 was broken.
Didn't fail any tests because the feature is behind a flag.
BUG=
Change-Id: I6009bfac27aa896e20446f002f5db707aab7e34c
Reviewed-on: https://chromium-review.googlesource.com/457040
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43984}
The data needed to be modified a bit to actually allow skipping over functions
based on it. In particular, we need to allow skipping over an unknown inner
scope structure (in the previous stage, we just had tests comparing the data
against some baseline truth, so it wasn't needed).
also removing the current "skip functions based on preparse data" logic,
since preparser data is not used any more. At a later stage, I'll consider
plugging the preparser-scope-analysis-data into that pipeline (so I don't want
to remove the full code yet).
Integration to the various forms of compilation is still incomplete; this CL
integrates just enough to get the minimal example to pass:
(function foo() {
function preparsed() {
var var1 = 10;
function skip_me() {
print(var1);
}
return skip_me;
}
return preparsed;
})()()();
BUG=v8:5516
Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2
Reviewed-on: https://chromium-review.googlesource.com/446336
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43908}
Parse tasks are still WIP so there is really no benefit turning them on.
Turn off irrelevant tests.
Fix duplicate parameters inverted logic.
Fix use_counts tracking.
Fix language mode, super_property, evals.
Fix modules and stack overflow.
BUG=v8:6093
Change-Id: I8567b36eef7b9de6799789e7520810bde9c86e5b
Reviewed-on: https://chromium-review.googlesource.com/455916
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43903}
The switch statement itself is part of the switch block.
However, the source position of the statement is outside of
the block. This leads to confusion for the debugger, if the
switch block pushes a block context: the current context is
a block context, but the scope analysis based on the current
source position tells the debugger that we should be outside
the scope, so we should have the function context.
R=marja@chromium.org
BUG=v8:6085
Review-Url: https://codereview.chromium.org/2744213003
Cr-Commit-Position: refs/heads/master@{#43744}
Materialized literal removal is a follow up to https://chromium-review.googlesource.com/443246
In addtion, remove ParserBase::Checkpoint; it was for restoring materialized
literal counts and expected property counts, but actually the expected property
count tracking was incorrect ("this" in arrow function param list binds to the
outside, so it's correct without the checkpoint):
(a, b = this.c = 0) => { }
BUG=
Change-Id: Ic097f6d2e7cb235166fb3a76af3bf5584bc167f0
Reviewed-on: https://chromium-review.googlesource.com/449733
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43579}
The pattern of creating a hidden catch scope occurs several times, so
define a helper for it.
BUG=
Change-Id: I5831378341d86d41bfb015bd3e687183cc79ac20
Reviewed-on: https://chromium-review.googlesource.com/448559
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43574}
This is always the single variable declared in the catch scope.
BUG=
Change-Id: I05ccc48f57394268432c9b5b8c76f9db1b3b6312
Reviewed-on: https://chromium-review.googlesource.com/448041
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43571}
BUG=
Change-Id: Id77205450d286be228b493deb69e1489a1e12895
Reviewed-on: https://chromium-review.googlesource.com/445906
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43501}
BUG=v8:6022
Change-Id: I54205cb3ecc2dd31ed62e55726f0ec5fcd202c30
Reviewed-on: https://chromium-review.googlesource.com/446349
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43500}
Previously, we over-approximated Scope::scope_calls_eval_ in
arrow functions: if either the outer scope or the arrow function
parameters had a direct eval call, we marked both scopes as calling
eval. This over-approximation kept getting us into trouble, though,
especially when eager or lazy parsing would disagree about the
"calls eval" bit.
This patch instead tracks eval calls accurately, using a boolean on
Scope::Snapshot that is reset as appropriately depending on whether
a particular AssignmentExpression turned out to be an arrow parameter
list or not.
BUG=chromium:691687
Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2
Reviewed-on: https://chromium-review.googlesource.com/446094
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43499}
This is more useful than always returning undefined.
BUG=v8:1569,v8:5978
Change-Id: Id10cf87f7865db1a85de412460eaead4e4bf3b62
Reviewed-on: https://chromium-review.googlesource.com/446846
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43498}
With the params (a, b, ...c) the param / variable declaration order used to be
"temp, temp, c, a, b". Now it is "temp, temp, a, b, c" as you'd expect. This
makes it easier for PreParser to match the parameter order of Parser.
R=verwaest@chromium.org
BUG=v8:5516
Change-Id: I79da04ef3f812bf52c032bed6263c009fecb7988
Reviewed-on: https://chromium-review.googlesource.com/447677
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43490}
