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}

Wasm frames are special in that they have a non-integer script id
in inspector. The way we treat script ids currently is a bit of a mess -
our runtime functions expected integer IDs while inspector has string
IDs (which contain integers, except for Wasm frames). This will need to
be cleaned up once more Wasm tests are added.

The meaning of line/column numbers has also changed; the old JS debug
API encoded the function index and byte offset into line/column numbers,
while inspector-based API actually translates into lines/columns in the
disassembly.

BUG=v8:5530

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

This makes sure the {kScratchRegister} is not used across macro
instructions (e.g. {LeaveFrame}) that would clobber its content.
Generally it is highly unsafe to use such scratch registers with a
life-range spanning macro instructions.

R=neis@chromium.org

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

TBR=littledan@chromium.org
BUG=

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

Unfortunately, there's currently no satisfying way of accessing scopes
of suspended generator objects through inspector. This CL implements
access to such scopes through runtime functions instead.

BUG=v8:5530

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

This makes the test in the bug ~10x faster. It could inadvertently make other things slower, so revert eagerly if included in a range where performance tanks.

BUG=chromium:666852

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

StepFrame is a combination of StepIn/StepOut, e.g. it breaks to the next
frame change. This is not part of the public API, but we want to keep it
for internal tests.

BUG=v8:5530

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

With this CL the regexp-parser-fuzzer uses the first byte of the fuzzer
input to select the regexp flag instead of executing each input with all
possible flags. Thereby the fuzzer can explore more inputs and with its
coverage metric will explore all flags only for interesting inputs.

I updated all files in test/fuzzer/regexp and added a random byte at the beginning. This byte is used by the fuzzer to determine the flag.

BUG=chromium:664436
R=yangguo@chromium.org

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

* Fix setting script-scope variables through inspector by internalizing
  their names.
* Reconstruct values of Number, String, and Boolean classes.
* Adapt a couple of tests for API restrictions.

BUG=v8:5530

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

BUG=chromium:667603
R=clemensh@chromium.org

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

BUG=chromium:664117

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

When disassembling functions for the inspector, we used an internal
text representation before. This CL implements the official text
format like it is understood by the spec interpreter.

Example output:
func $main (param i32) (result i32)
block i32
  get_local 0
  i32.const 2
  i32.lt_u
  if
    i32.const -2
    return
  end
  get_local 0
  call_indirect 0
end

R=rossberg@chromium.org, titzer@chromium.org
BUG=chromium:659715

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

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

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

This fixes stack unwinding to always recompute the stack pointer for
interpreted frames. For frames materialized by the deoptimizer we elide
the handler frame in between, hence arguments being pushed on the stack
will no longer be pushed into the handler frame but into the interpreted
frame directly.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-662830
BUG=chromium:662830

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

BUG=chromium:667689
R=jarin@chromium.org

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

The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results.

Other changes in this CL:
- DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front.
- I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan.
- I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention.
- I removed CodeDeoptEvent::position, as it is no longer used.

R=alph@chromium.org

BUG=v8:5432

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

R=hablich@chromium.org
NOTRY=true
NOTREECHECKS=true

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

TurboFan can indeed comsume NumberOrOddball feedback for abstract
relational comparisons, so we should just provide it from Ignition.

Drive-by-fix: Add a DCHECK to protect against abstract/strict equality
number comparison accidentially utilizing Oddball feedback.

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

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

This code should not access bytes out of the permitted range in order to check
the range of a possible UTF-8 value. Instead, the length check should occur
before such checks.

BUG=chromium:667260, chromium:662822

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

R=jshin@chromium.org

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

Make use of the previously introduced String feedback for compare
operations in TurboFan.

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

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

BUG=none
R=yangguo@chromium.org

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

BUG=chromium:651324

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

 - Simd Scalar lowering should be conditionally disabled if the architecture has a native SIMD implementation.
 - Enable scalar lowering tests on all architectures instead of only x64.

R=bbudge@chromium.org, aseemgarg@chromium.org

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

The verifier needs to use the block and assessments in that block corresponding to
a predecessor of a "pending" assessment. Not doing that causes incorrect
assessments when 2 locations are swapped.

BUG=665402

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

This fixes a bug found by the fuzzer where we would attempt to
dereference a null handle if memory allocation failed. In this case,
the failure was because the amount of memory requested was above V8's
hardcoded limit.

BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=666741

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

Export JS_API_OBJECT_TYPE, JS_SPECIAL_API_OBJECT_TYPE.

Exports JSObject::kHeaderSize to ease the inspection of internal fields
in llnode.

BUG=
R=machenbach

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

Instead of directly using v8_enable_inspector_override from
build_overrides/v8.gni in all the GN configs, set a v8_enable_inspector
variable based on v8_enable_inspector_override and use that everywhere.
This is the more common pattern seen in over projects, and reduces the
need to include //build_overrides/v8.gni in many files.

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

R=titzer@chromium.org
CC=mtrofin@chromium.org

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

R=mstarzinger@chromium.org,clemensh@chromium.org
BUG=

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

This pre-calculates and stores a vector of bytecode offsets, and then allows
one to iterate over it backwards. This could probably be adapted to a
bidirectional/random access iterator if we wanted to, but for now reverse
is all we need.

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

Refactors the bytecode array iterator to separate the iteration and the
bytecode parameter access, placing the latter into a separate
super-class. This will allow us to have other forms of access, e.g.
reverse iteration.

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

BUG=v8:5296

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

Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ )

Reason for revert:
Wronged it even more.

Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> 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
> Cr-Commit-Position: refs/heads/master@{#41142}

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

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