R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=

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

Because it was confusing seeing U8(negative value).

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

BUG=

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

Adds CSA::Print(const char* s), which generates a runtime call to
Runtime::kGlobalPrint with a line-terminated ASCII string constant,
and CSA::DebugPrint(const char* prefix, Node* tagged_value), which
emits a runtime call to Runtime::kDebugPrint() with the tagged
value, optionally prefixed by an ascii string constant.

These simplify debugging TF builtins by providing a tool to easily
observe the contents of values at arbitrary points in a program,
without stepping endlessly through assembly in a debugger, and to
easily observe the path taken through a TF builtin.

These methods do not generate code in release builds.

BUG=v8:5268
R=ishell@chromium.org, danno@chromium.org, bmeurer@chromium.org

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

Also tidy some JS style in the file.

BUG=chromium:673246
NOTRY=true

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

R=titzer@chromium.org, clemensh@chromium.org

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

We did not smi-check the spread argument here, meaning we tried to take the map
of a smi, resulting in segfaults which clusterfuzz found.

Also added tests that exercise this path.

BUG=685086

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

[parser]: Skipping inner funcs / initial implemetation of storing scope analysis data from preparsed scopes.

The data produced at the moment only contains information about scope type +
positions, and only the most trivial tests pass.

Upcoming CLs will extend the data to contain information about variables (once
PreParser can produce it) and add more test cases.

BUG=v8:5516

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

R=rossberg@chromium.org
BUG=

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

After decoding an invalid function name (e.g. OOB), we stored the parsed
offset and length into the WasmFunction anyway, resulting in a runtime
CHECK failure later on.
This CL fixes this, and adds a regression test.

R=titzer@chromium.org
CC=mtrofin@chromium.org, bradnelson@chromium.org
BUG=chromium:684858

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/dbe38ca..24cce87

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/58fecbe..68adbeb

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

BUG=v8:5887

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

R=rossberg@chromium.org
BUG=

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

The default stack size of a background thread is 512KB on MacOSX. We default to
1MB stack checks when compiling JS code, so we need to increase this limit
to enable compilation of JS code onto background threads.

Corresponding Chromium CL is https://codereview.chromium.org/2640803002/

BUG=v8:5203

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

It's a common pattern to create a Variable and immediately initialize
it. This adds a new constructor to make that pattern more natural.

BUG=

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

This fixes the checks of accumulator usage flags in the computation of
the interpreter register liveness during bytecode analysis. The usage
flags at hand are bit patterns as opposed to flat enum values. Use the
safe accessors instead of plain comparison.

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

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

This adds support to constant-fold JSGetSuperConstructor(constructor)
for constructors with stable maps, i.e. where we can add a stability
dependency on the constructors map to get notified when the [[Prototype]]
of constructor changes.

R=petermarshall@chromium.org
BUG=v8:5517

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

This test checks that counters accurately reflect the allocated size.
There's an edge case that can occur when, previously to the allocation,
the page does not have enough space left to allocate the requested
object - then we move on to a fresh page, fill the remaining space of
the old page with a filler object, and allocate the requested object on
the new page.

The counters will show the size of the filler object plus the requested
object size, while the test expects only the requested size.

This CL fixes that case by performing two GCs to clear out new space.

BUG=

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

BUG=

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

- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.

- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.

- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.

- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.

- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.

- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.

- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.

With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).

Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)

Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)

Additionally: WillHandle and DidHandle were migrated to PromiseHook API.

More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE

BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org

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

In the JSCallReducer we'd inline certain builtins like the Array
constructor or Function builtins across native contexts, which at
this point should be mostly safe, but might lead to cross context
leaks in the future (as it's not obvious that the JSCallReducer)
doesn't maintain this invariant. So better safe than sorry.

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

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

  port f9367847 (r42632)

  original commit message:
  We can share almost all of the architecture-specific builtin code with super-call-with-spread.

  Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread,
  in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.

BUG=

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

  port d287c819 (r42620)

  original commit message:
  [RELAND with one change: until literal arrays are rooted in the outer
  feedback vector (coming in the next days), the runtime-scope.cc change
  is held off.]

  When a function is declared in global scope, the closure is created
  by the DeclareGlobals runtime service. It needs a pointer to the
  literals array, already allocated in the feedback vector. This
  fixes a bug where it's behavior wasn't in sync with CreateClosure,
  which accepts the literals from the vector.

  This enables a follow-on performance improvement in the CompileLazy
  builtin.

BUG=

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

Array.prototype.concat does not properly handle JSProxy species that will
modify the currently visited array.

BUG=682194

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

We're converting the build_overrides system to the new default_args list of
overrides that can be listed in the toplevel .gn file. This will allow args to
be set on a per-repo basis.

This change conditionally adds the variables currently defined in
build_overrides/v8.gni to build args. This allows V8's build to be used in both
the new and old systems. Once all Chrome and pdfium have been updated, v8's
build overrides and the conditional checks around the new args can be removed.

BUG=684096

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

Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).

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

The property backing store size depends on the number of
index keys. Pass index keys to the factory function instead
calculating the size outside.

R=verwaest@chromium.org

BUG=v8:5625

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

BUG=v8:5885

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

BUG=v8:5549

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

R=ahaas@chromium.org,rossberg@chromium.org
BUG=chromium:575167

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

Speculative reason for issue 684481.

BUG=chromium:684481
TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,

Original issue's description:
> [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203, v8:5215
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42562}
> Committed: https://chromium.googlesource.com/v8/v8/+/4b0101d369af121a6daf5e5c731cb939c026d526

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

We can share almost all of the architecture-specific builtin code with super-call-with-spread.

Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.

BUG=v8:5511

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

Using a Handle<Foo> as a member doesn't require including foo.h

R=mstarzinger@chromium.org
BUG=v8:5402

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

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

BUG=chromium:669242

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

R=ahaas@chromium.org
BUG=v8:5882

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

BUG=chromium:679724

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

It was a scary function which handled all possible old-fashioned and
for-each statements at one go. Split it to multiple smaller functions
and made the top level logic clearer.

BUG=

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

This disables optimizations when using typed float arrays in
correctness fuzzer test cases. Otherwise, different NaN patterns
in float typed arrays might lead to different observations when
using the buffer in an int array view.

BUG=chromium:683579
NOTRY=true
TBR=Jarin, mvstanton, Igor Sheludko

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

The "sloppy eval in default param" cases will be useful for the future
tests which assert that parser and preparser produce the same scopes.

BUG=v8:5501, v8:5516

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

Implement stepping by remembering the current step action in the wasm
interpreter handle in WasmDebugInfo, and using it when continuing
execution in the interpreter.
The control flow is as follows: After module compilation, the user sets
a breakpoint in wasm. The respective function is redirected to the
interpreter and the breakpoint is set on the interpreter. When it is
hit, we notify all debug event listeners, which might prepare stepping.
When returning from these listeners, before continuing execution, we
check whether stepping was requested and continue execution in the
interpreter accordingly.

Stepping from Wasm to JS and vice versa will be implemented and tested
in a follow-up CL. Testing this requires breakpoints and stepping in
Wasm to be exposed via the inspector interface, such that we can write
an inspector test. This mixed JS-Wasm-execution is hard to set up in a
cctest.

R=titzer@chromium.org, yangguo@chromium.org
BUG=

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