This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.

BUG=v8:5405

Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}

This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.

BUG=v8:5405

Review-Url: https://codereview.chromium.org/2359513002
Cr-Commit-Position: refs/heads/master@{#39566}

To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.

BUG=v8:3093

Review-Url: https://codereview.chromium.org/2350363002
Cr-Commit-Position: refs/heads/master@{#39565}

This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
  is a Promise, from the awaited value to the Promise under construction
  in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
  stack, to the Promise under construction in the async function that
  surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
  Promise from an async function)

In this reland, the caught tests are broken up into four parts to avoid
timeouts.

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2346363004
Cr-Commit-Position: refs/heads/master@{#39564}

Also simplify Factory::NewModule to take only the SharedFunctionInfo.

R=neis@chromium.org
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2355033002
Cr-Commit-Position: refs/heads/master@{#39563}

The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}

    Port 7f3d15aa

    Original commit message:
    In ignition, arguments to function calls and function constructors are
    pushed onto the stack before calling the function. It is required to check
    that stack does not overflow when pushing the arguments.

    R=mythria@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

Review-Url: https://codereview.chromium.org/2356583003
Cr-Commit-Position: refs/heads/master@{#39561}

Fix a typo in TypeFeedbackVector::ComputeCounts, where we would not
skip the interpreter binary/compare op IC slots for fullcodegen, and
thus mess up the heuristics for tearing up.

TBR=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2353513006
Cr-Commit-Position: refs/heads/master@{#39560}

R=adamk@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2351643006
Cr-Commit-Position: refs/heads/master@{#39559}

This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.

BUG=v8:5409

Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}

Here we only change the type of the slot set fields to atomic values and use CAS to change the state. There is no change in behavior or semantics of the slot set.

BUG=chromium:648568

Review-Url: https://codereview.chromium.org/2353553003
Cr-Commit-Position: refs/heads/master@{#39557}

BUG=chromium:647329
R=titzer@chromium.org
TEST=unittest EncoderTest.Regression_647329

Review-Url: https://codereview.chromium.org/2355803002
Cr-Commit-Position: refs/heads/master@{#39556}

Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.

As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.

This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.

BUG=

Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}

- Eliminates *all* copies in the process.
- Moves (nearly) all functionality into Scanner::BookmarkScope.
- Significant code reduction.

[Needs to be rebased once crrev.com/2347883002 lands. All changes in *parser* are from that CL.]

R=marja@chromium.org
BUG=v8:4947

Review-Url: https://codereview.chromium.org/2341323002
Cr-Commit-Position: refs/heads/master@{#39554}

This makes sure generator functions are marked as optimizable for all
configurations where the BytecodeGraphBuilder is used. Note that as
usual AstNumbering is just a heuristic and the underlying compiler can
still bailout from optimization when the compilation pipeline chooses
another compiler that does not support generator functions.

R=bmeurer@chromium.org,hablich@chromium.org

Review-Url: https://codereview.chromium.org/2353793003
Cr-Commit-Position: refs/heads/master@{#39553}

Due to a typo, long branches were emitted instead of short branches, and the
code would stop working at all in the situation when long branches must be
emitted. This patche fixes this issue.

TEST=mjsunit/wasm/embenchen/lua_binarytrees
BUG=

Review-Url: https://codereview.chromium.org/2351143002
Cr-Commit-Position: refs/heads/master@{#39552}

The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887

Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}

Refactors CodeStubAssembler::AllocateJSArray to share code.

BUG=chromium:608675

Review-Url: https://codereview.chromium.org/2304573004
Cr-Commit-Position: refs/heads/master@{#39550}

This will allow to simplify the miss part of store IC handlers when we decide
to pass value/slot/vector on the stack.

BUG=v8:5407

Review-Url: https://codereview.chromium.org/2351643005
Cr-Commit-Position: refs/heads/master@{#39549}

This means we can no longer take the closure's context to parse, but
need to rely on the outer scope info.

Since it's not possible to get that, however, for lazy functions, we
introduce a new field to SharedFunctionInfo that stores the outer scope
info whenever available.

BUG=v8:5215
R=marja@chromium.org,verwaest@chromium.org,jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2358503002
Cr-Commit-Position: refs/heads/master@{#39548}

This commit ensures that the d8 shared library build uses the same logic as
the standard static build by exporting relevant functions and classes.

BUG=chromium:646337

Committed: https://crrev.com/2c10ca8086a4d595ecf9aa843d2031b068470d65
Review-Url: https://codereview.chromium.org/2342563002
Cr-Original-Commit-Position: refs/heads/master@{#39503}
Cr-Commit-Position: refs/heads/master@{#39547}

R=verwaest@chromium.org,marja@chromium.org

Review-Url: https://codereview.chromium.org/2351823005
Cr-Commit-Position: refs/heads/master@{#39546}

Removes some unnecessary probing in TemplateHashMapImpl, in
particular probing a second time in LookupOrInsert after the
first probe came up with an empty value.

Review-Url: https://codereview.chromium.org/2349163002
Cr-Commit-Position: refs/heads/master@{#39545}

BUG=

Review-Url: https://codereview.chromium.org/2347073003
Cr-Commit-Position: refs/heads/master@{#39544}

... because the latter automatically respects the desired calling convention.

BUG=v8:5407

Review-Url: https://codereview.chromium.org/2350423002
Cr-Commit-Position: refs/heads/master@{#39543}

BUG=

Review-Url: https://codereview.chromium.org/2357563002
Cr-Commit-Position: refs/heads/master@{#39542}

BUG=chromium:642111

Review-Url: https://codereview.chromium.org/2358523003
Cr-Commit-Position: refs/heads/master@{#39541}

Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.

Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.

Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.

BUG=v8:5267
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2354853002
Cr-Commit-Position: refs/heads/master@{#39540}

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2357573002
Cr-Commit-Position: refs/heads/master@{#39539}

Moves the hashmap's allocator from being a parameter in the various
hashmap functions, to being a field in the hashmap itself. This

1. Protects against incorrectly passed allocators, and
2. Cleans up the API so that e.g. callers don't have to store their
   allocator

This is part of a wider set of changes discussed in:
https://groups.google.com/forum/#!topic/v8-dev/QLsC0XPYLeM

Review-Url: https://codereview.chromium.org/2345233003
Cr-Commit-Position: refs/heads/master@{#39538}

Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.

BUG=v8:5263

Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}

Internalize the ast-value-factory before tracing in trace-parse. Otherwise the string-handle isn't available yet

BUG=

Review-Url: https://codereview.chromium.org/2348373004
Cr-Commit-Position: refs/heads/master@{#39536}

... because the latter automatically respects the desired calling convention.

BUG=v8:5407

Review-Url: https://codereview.chromium.org/2358533002
Cr-Commit-Position: refs/heads/master@{#39535}

When an allocation for a parent object is pretenured, also propagate
that to all allocations for objects that are (potentially) stored into
the parent object.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2348293003
Cr-Commit-Position: refs/heads/master@{#39534}

BUG=v8:4947

Review-Url: https://codereview.chromium.org/2347883002
Cr-Commit-Position: refs/heads/master@{#39533}

This would've caught the "preparser tracking only unresolved variables
but no declarations is not enough" bug.

BUG=

Review-Url: https://codereview.chromium.org/2350683002
Cr-Commit-Position: refs/heads/master@{#39532}

Avoid internalizing on-the-fly now that scope analysis and natives syntax
runtime calls no longer require internalized AST values. This should be
more efficient by avoiding extra branches on every AST value creation.

BUG=v8:5215, chromium:634953

Review-Url: https://codereview.chromium.org/2328593002
Cr-Commit-Position: refs/heads/master@{#39531}

Adds template parameters for the TemplateHashMapImpl for the key and
value type, to allow them to be something other than pointers. To keep
the impact of this patch low, uses of TemplateHashMapImpl set these
types to void* to emulate the previous behaviour.

This is part of a wider set of changes discussed in:
https://groups.google.com/forum/#!topic/v8-dev/QLsC0XPYLeM

Review-Url: https://codereview.chromium.org/2343123002
Cr-Commit-Position: refs/heads/master@{#39530}

R=vogelheim@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2354683003
Cr-Commit-Position: refs/heads/master@{#39529}

R=littledan@chromium.org
BUG=v8:5339

Review-Url: https://codereview.chromium.org/2332333002
Cr-Commit-Position: refs/heads/master@{#39528}