The catch scopes were created with the wrong parent scope.

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

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

Since we are specializing on the native context, we don't have to load
the vector from the closure. For one thing, this reduces the machinery for
nodes that use a vector in their generic incarnation.

BUG=
R=mstarzinger@chromium.org

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

This fixes the message reported via the {TypeError} thrown when trying
to call a non-constructable function as a constructor. Also adds some
more related message tests for similar exceptions.

R=bmeurer@chromium.org
TEST=message/call-non-constructable
BUG=chromium:661579

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

The implementation was removed in http://crrev.com/2248393002.

R=rmcilroy@chromium.org

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

For dictionary-mode receivers, the KeyedStoreGeneric stub can store
properties directly in most cases. Doing so avoids the need to have
an entry in the stub cache for every map/property combination.

Original review: https://codereview.chromium.org/2504403005/

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

In order for profiles of optimized code to have accurate source
positions, we need to prepare for this when compiling. If the profiler
is enabled late, this may be missing, leading to inaccurate profile
data. A compromise to solve this is to prepare for accurate positions if
the debugger (and therefore DevTools) is active, even if we are not
currently capturing a profile.

The alternative is to deopt everything upon profiling, but that would
affect the profile significantly.

R=alph@chromium.org, bmeurer@chromium.org, neis@chromium.org, tebbi@chromium.org

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

Eval calls are tracked by ParserBase::CheckPossibleEvalCall which
doesn't use (Pre)?Parser::IsDirectEvalCall.

Also we no longer seem to care about IsBinaryOperation (Parser didn't
have it either).

BUG=

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

R=jgruber@chromium.org
BUG=v8:5530

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

RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
Review-Url: https://codereview.chromium.org/2511093002
Cr-Original-Commit-Position: refs/heads/master@{#41142}
Cr-Commit-Position: refs/heads/master@{#41214}

[ic] Don't enable property cell mode for a LoadGlobalIC if the holder is a different global object than the receiver.

Test contributed by crlf0710 <crlf0710@gmail.com>.

BUG=v8:5552

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

This is similar to how the native context has an empty function set up as it's closure field.

BUG=666984

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

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

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

Passing in the isolate to retrieve the heap constants (undefine, the_hole, null)
has a positive performance impact.

BUG=

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

BUG=v8:4280,v8:5657

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

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #13 id:240001 of https://codereview.chromium.org/2471883003/ )

Reason for revert:
Test crashes after an unrelated revert: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7189

Reverting because of recommendation from WASM team.

Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
>  - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
>  - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
>  - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
>  - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
>  R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
> Cr-Original-Commit-Position: refs/heads/master@{#41121}
> Cr-Commit-Position: refs/heads/master@{#41198}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Revert of [stubs] KeyedStoreGeneric: inline dictionary property stores (patchset #5 id:100001 of https://codereview.chromium.org/2504403005/ )

Reason for revert:
Blocks roll: https://codereview.chromium.org/2526573002/

Original issue's description:
> [stubs] KeyedStoreGeneric: inline dictionary property stores
>
> For dictionary-mode receivers, the KeyedStoreGeneric stub can store
> properties directly in most cases. Doing so avoids the need to have
> an entry in the stub cache for every map/property combination.
>
> Committed: https://crrev.com/af168e330e95c4460fd1bb7734f0e9a750f2e748
> Cr-Commit-Position: refs/heads/master@{#41185}

TBR=ishell@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Revert of [cleanup] CodeStubAssembler: s/compiler::Node/Node/ (patchset #2 id:20001 of https://codereview.chromium.org/2519093002/ )

Reason for revert:
Blocks revert of roll blocker: https://codereview.chromium.org/2528583002/

Original issue's description:
> [cleanup] CodeStubAssembler: s/compiler::Node/Node/
>
> Reducing visual clutter.
>
> Committed: https://crrev.com/36a17e87d86d2d978b64eb37044c9e9f98ebea67
> Cr-Commit-Position: refs/heads/master@{#41187}

TBR=ishell@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

BUG=v8:5530,chromium:667218

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

  port 09255541 (r41135)

  original commit message:
  This removes the deprecated generator support for resumable functions
  from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
  triggers Ignition for most resumable functions, with this change we make
  said heuristic a hard choice and remove the deprecated code. This also
  has the advantage that any suspended {JSGeneratorObject} instance on the
  heap is guaranteed to have code based on a bytecode array.

BUG=

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

  port d4f01b8a (r41108)

  original commit message:
  Add fast paths for holey smi and object arrays to
  Function.prototype.apply, Reflect.apply and Reflect.construct.

BUG=

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

BUG=

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

The AstGraphBuilder pipeline is only used for asm.js now, so the whole
type feedback mechanism is essentially dead code currently, thus we
better nuke it.

BUG=v8:5267,v8:5657

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

Wsign-compare exposed this error in s390 31-bit debug
build.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

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

  port 93c65952 (r40887)

  original commit message:
  This changes {FrameState} nodes modeling "after" states to use bytecode
  offsets pointing to the deoptimizing bytecode. This is in sync with the
  normal execution, as the bytecode offset is advanced after operations
  complete in regular bytecode handlers.

  The change is necessary to ensure lazy deoptimized frames contain an
  accurate bytecode offset while they are on the stack. Such frames can be
  inspected by various stack walks. The continuation builtin will advance
  the bytecode offset upon return.

BUG=

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

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Commit-Position: refs/heads/master@{#41198}

This roll includes:
  - [inspector_protocol] Introduce protocol::Serializable [1]

[1] https://codereview.chromium.org/2526603002

BUG=chromium:350797
R=dgozman@chromium.org

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

Wsign-compare was recently added which exposed this
issue. Using the correct type fixes the error.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

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

This roll includes:
  - Support config.protocol.options which defines which part of protocol definition should be generated. [1]
  - [inspector_protocol] Allow custom json parser. [2]
  - [inspector_protocol] Allow overriding specific config values. [3]
  - [inspector_protocol] Fix NoneType error when parsing config_values. [4]
  - [inspector_protocol] Support chromium code style. [5]
  - [inspector_protocol] Support features for content/ generator. [6]
  - [inspector_protocol] Fixed domain_json["has_exports"] flag for exported domains [7]

[1] https://codereview.chromium.org/2482993002
[2] https://codereview.chromium.org/2490733002
[3] https://codereview.chromium.org/2482093004
[4] https://codereview.chromium.org/2490823002
[5] https://codereview.chromium.org/2495353004
[6] https://codereview.chromium.org/2509573006
[7] https://codereview.chromium.org/2515343005

BUG=none
R=dgozman@chromium.org

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

Now that we have a JumpLoop bytecode, we can heavily simplify the
branch/loop analysis by assuming that only JumpLoop bytecodes are
backwards edges, and performing the loop analysis as a single
(backwards) pass.

This allows us to get rid of the branch analysis entirely, and builds a
framework to do liveness analysis in the same pass.

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

Previous fuzzer fix broke the case when the pending assessment came from the same
block. In that case, the assessments table does not have an entry yet for the block,
because we register only when we're done processing a block.

BUG=667745

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

We had error messages that exceeded the current limit of 100
characters, resulting in the newline being cut off.
This CL also reverts http://crrev.com/2503423006 since it did not fix
this issue.

BUG=chromium:660016
R=machenbach@chromium.org, titzer@chromium.org

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

The GetPositionInfo function only operates on WasmCompiledModule, so it
should be a method of that class.
This CL also splits the method in two, such that I can reuse the
GetContainingFunction method for breakpoint support.

R=titzer@chromium.org
BUG=chromium:613110

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

Wrapper creation for import functions with i64 return values on 32-bit
platforms crashed because the number of return values of the wrapper
did not match the number of input nodes of the return node.

The issue is fixed by not creating special wrappers for 32-bit platforms
in the first place. This is valid because wrappers with i64 return
values are never actually executed.

R=titzer@chromium.org
BUG=v8:5661

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

The tests were relying on early errors which we don't produce since we
now preparse more often.

BUG=v8:2728, v8:5501, v8:5663

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

The handwritten-assembly implementations of both dispatcher and
generic stub have been replaced by Turbofan-generated stubs.

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

Reducing visual clutter.

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

BUG=chromium:667388

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

For dictionary-mode receivers, the KeyedStoreGeneric stub can store
properties directly in most cases. Doing so avoids the need to have
an entry in the stub cache for every map/property combination.

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

BUG=chromium:667388

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

... but be less pessimistic about context allocation (see below).

We might have just (pessimistically) context-allocated a variable based
on references coming from an inner function, but after that we still
need to set maybe_assigned (pessimistically).

This makes test-parsing/InnerAssignment pass with
FLAG_lazy_inner_functions.

This was undetected until now because we didn't have lazy parsing enabled
for small scripts.

Less pessimistic approach: now that inner functions laziness decisions
are stable (if we have once compiled a piece of code with lazy inner
functions, we never compile the same code with eager inner functions),
we don't need to be as pessimistic with context allocation as before.

BUG=v8:5501

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