[tracing] Avoid Gcc compilation fail by declaring AddTraceEvent function in Class derived from Platform Class.

  The CL #39789 (https://codereview.chromium.org/2367603002 ) caused the Gcc compilation fail for v8 debug mode.
  The error message was:
  In file included from .././include/libplatform/v8-tracing.h:13:0,
                   from .././src/libplatform/default-platform.h:14,
                   from ../src/libplatform/default-platform.cc:5:
  .././include/v8-platform.h:169:20: error: ‘virtual uint64_t v8::Platform::AddTraceEvent(char, const uint8_t*, const char*, const char*, uint64_t, uint64_t, int32_t, const char**, const uint8_t*, const uint64_t*, unsigned int)’ was hidden [-Werror=overloaded-virtual]
     virtual uint64_t AddTraceEvent(
                      ^
  In file included from ../src/libplatform/default-platform.cc:5:0:
  .././src/libplatform/default-platform.h:55:12: error:   by ‘virtual uint64_t v8::platform::DefaultPlatform::AddTraceEvent(char, const uint8_t*, const char*, const char*, uint64_t, uint64_t, int32_t, const char**, const uint8_t*, const uint64_t*, std::unique_ptr<v8::ConvertableToTraceFormat>*, unsigned int)’ [-Werror=overloaded-virtual]
     uint64_t AddTraceEvent(
              ^

  This CL fixed this issue by adding "using Platform::AddTraceEvent;" before all declarations of AddTraceEvent functions in Classes derived from Platform Class.

BUG=

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

BUG=

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

BUG=v8:4915

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

BUG=

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

- Select Total group by default, this way graphs show up immediately
- Groups can now be toggled much like pages and versions

BUG=
NOTRY=true

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

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

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

Add a CanonicalizationMode to CodeStubAssembler::ChangeFloat64ToTagged,
so clients can request Smi canonicalization when desired, but otherwise
get Crankshaft/Fullcodegen compatible behavior of just boxing the double
into a HeapNumber.

R=verwaest@chromium.org
BUG=v8:5268

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

This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.

Drive-by-fixes: Make sure the JSRegExp::lastIndex field stays Smi
if possible (otherwise we tank the regexp benchmark in Octane).

CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_mac64_rel,v8_mac64_dbg
R=jarin@chromium.org
BUG=v8:5267

Committed: https://chromium.googlesource.com/v8/v8/+/6a939714e991ebf10d56ddbd2869325cca99c0ef
Committed: https://crrev.com/ee158e6c4cc896479a32245432a3c2fdd31bcb73
Committed: https://crrev.com/ddf792beb3a72f6dba83e94fc8ada03ebf1630bd
Review-Url: https://codereview.chromium.org/2367593003
Cr-Original-Original-Commit-Position: refs/heads/master@{#39692}
Cr-Original-Commit-Position: refs/heads/master@{#39748}
Cr-Commit-Position: refs/heads/master@{#39803}

Even after https://codereview.chromium.org/2371963002 we still did not
always store a Smi into the JSTypedArray::length field, the runtime
function %TypedArrayInitializeFromArrayLike was still storing whatever
it got from the JavaScript code, which is highly dependent on internal
decisions of the ICs and the representation selection in the optimizing
compilers, so that's pretty fragile.

R=verwaest@chromium.org
BUG=chromium:650933

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

Rolling v8/build to 5e4ffb5c8928fe5afacd1b1b0f2bb732cdc0d77c

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to 5258fd5cfb62ec917c9258ce9089c62e17aee5dc

Rolling v8/tools/clang to f991b268a2441c4bc09b9cafdb3af797a13729fe

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

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

Previously we'd have a scope in the main zone, and another in the temp zone. Then we carefully copied back data to the main zone. This CL changes it so that the scope is just fixed up to only contain data from the main zone. That avoids additional copies and additional allocations; while not increasing the care that needs to be taken. This will also make it easier to abort preparsing while parsing using a temp zone.

BUG=

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

As a side-effect, this lets us remove bit_field_2_ from FunctionLiteral.

R=verwaest@chromium.org
BUG=v8:5209

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

!0 -> true and !1 -> false etc in the parser.
This clashes with some of the typing logic in asm.js,
and can show up in some real programs in the wild (at least in past asm.js
versions).

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
R=aseemgarg@chromium.org,jpp@chromium.org

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

R=adamk@chromium.org
BUG=

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

BUG=

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

[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.

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

Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
Review-Url: https://codereview.chromium.org/2345593003
Cr-Original-Commit-Position: refs/heads/master@{#39678}
Cr-Commit-Position: refs/heads/master@{#39795}

BUG=chromium:406277

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

If promise was resolved before adding handler in Runtime.evaluate method then this callback won't be called. We need to run microtasks after adding handlers.

R=dgozman@chromium.org,alph@chromium.org

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

TBR=klaasb@google.com

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

Previously passing in the PromiseNopResolver function to the Promise
constructor would result in creating the resolving functions to be in
passed in to the executor, but the PromiseNopResolver does not use
these resolving functions resulting in wastefully creating these closures.

Instead we pass in the promiseRawSymbol to the promise constructor
so that these unnecessary resolving functions are not created.

BUG=v8:5046

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

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

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

Drive-by: Use perfect forwarding for AddTraceEvent arguments.

BUG=406277

Committed: https://crrev.com/dcac49af485fe5d4c0027f153901435dbb29c232
Review-Url: https://codereview.chromium.org/2367603002
Cr-Original-Commit-Position: refs/heads/master@{#39742}
Cr-Commit-Position: refs/heads/master@{#39789}

This patch moves the following parsing method to ParserBase:

- DesugarAsyncFunctionBody, renamed to ParseAsyncFunctionBody
- ParseAsyncFunctionExpression, renamed to ParseAsyncFunctionLiteral
- ParseAsyncFunctionDeclaration

It renames the parser implementation methods:

- ParseArrowFunctionFormalParameterList -> DeclareArrowFunctionFormalParameters
- ParseArrowFunctionFormalParameters -> AddArrowFunctionFormalParameters

It also eliminates method ParseAsyncArrowSingleExpressionBody.

R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N

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

We must not throw when seeing a cycle while trying to resolve a name through
star exports.  (It may be surprising that we do have to throw when seeing an
ambiguity, but this is what the spec says.)

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

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

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

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

BUG=

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

This flag is meant to control whether we add a special context-free
entry to the optimized code map or not. A usage of the flag was
bogus.

BUG=

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

SmiMax will be used in a follow-up commit.

BUG=

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

When we OSR using Turbofan, we would set the function to be optimized
on the next call, irrespective of the runtime profiler's previous
decisions - such as compiling for baseline. It seems more prudent to
always make these decisions in the runtime profiler where the data is
available.

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

BUG=

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

The same information can be obtained by processing --trace-gc-nvp output
or using trace event and GC metric of catapult in Chrome.

BUG=

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

The test driver fails once in a while with no output when
listing the tests on windows, causing the testing to not
even start.

This should make that less likely if there's a flaky crash
when listing the tests.

BUG=v8:5438

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

A page now belongs either the nursery *or* the intermediate gen. The page that
contained objects of both spaces is removed in this change.

BUG=chromium:636331

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

The bytecode offset parameter was Int32, but everywhere else it's an IntPtr.

BUG=

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

This makes sure we only replace load operations for fields on virtual
objects. Even though data flow information for non-virtual (escaping)
allocations is available, it might be inaccurate in certain situations
where object state hasn't been cleared.

R=jarin@chromium.org
TEST=mjsunit/compiler/regress-escape-analysis-indirect

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

I need this API for https://codereview.chromium.org/1609343002/.

BUG=483722

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

The call to RegExpSubclassExec may refer to a different exec method
since splitter is newly constructed previously to the call.

BUG=v8:5351

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

The lowering of {JSToBoolean} operators in {JSTypedLowering} inserts
loads that are not part of the effect chain. This does not play well
with effect-sensitive data flow analysis (e.g. escape analysis). This
removes the lowering in question, we can implement it using a dedicated
simplified operator eventually if needed.

R=bmeurer@chromium.org
TEST=mjsunit/wasm/embenchen/lua_binarytrees

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

These crashes were caused by an invalid pointer stored in a tagged
variable in SubStringStub. This can be reproduced by calling the stub on
an external string and ensuring GC kicks in on the subsequent
allocation.

Only the TurboFan implementation of SubStringStub is affected, the current
PlatformStub implementation handles this case just fine.

BUG=chromium:649967

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

Even after https://codereview.chromium.org/2371963002 we might still
create JSTypedArray instances where the length field is a HeapNumber,
especially when TurboFan no longer canonicalizes all values in Smi
range to Smis (which we try to achieve currently). This adds strict
checking for this fact now.

R=mstarzinger@chromium.org

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