Revert of [parser] Refactor of ParseClass* and ParseNativeDeclaration (patchset #7 id:120001 of https://codereview.chromium.org/2368083002/ )

Reason for revert:
Blocks reverting https://codereview.chromium.org/2368313002

Original issue's description:
> [parser] Refactor of ParseClass* and ParseNativeDeclaration
>
> This patch moves the following parsing method to ParserBase:
>
> - ParseClassDeclaration
> - ParseClassLiteral
> - ParseNativeDeclaration
>
> R=adamk@chromium.org, marja@chromium.org
> BUG=
> LOG=N
>
> Committed: https://crrev.com/7818355363b7a66ff7709e33c72bfdef5eb21450
> Cr-Commit-Position: refs/heads/master@{#39814}

TBR=adamk@chromium.org,marja@chromium.org,nikolaos@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/2380663002
Cr-Commit-Position: refs/heads/master@{#39820}

R=jarin@chromium.org

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

Add documentation for Has(), HasOwnProperty(), and HasRealNamedProperty()
that points out their differences and links to the other functions.

BUG=v8:5433

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

TurboFan lowering (see [0]) of ConsString creation cannot ensure that
the first part of the cons string is non-empty without introducing a phi
and negatively impacting performance.

This modifies ConsStringIterator to allow empty first parts of
ConsStrings.

BUG=v8:5440

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

BUG=
NOTRY=true

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

Revert of Preparse top-level functions in discardable zones (patchset #2 id:20001 of https://codereview.chromium.org/2374963002/ )

Reason for revert:
Needed to revert https://codereview.chromium.org/2368313002 which slows down asm.js code

Original issue's description:
> Preparse top-level functions in discardable zones
>
> BUG=
>
> Committed: https://crrev.com/ff8cfa9e5e8495165291ddf6e01dba3f8cb5a177
> Cr-Commit-Position: refs/heads/master@{#39809}

TBR=marja@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/2375013002
Cr-Commit-Position: refs/heads/master@{#39815}

This patch moves the following parsing method to ParserBase:

- ParseClassDeclaration
- ParseClassLiteral
- ParseNativeDeclaration

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

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

When the inline lookup on a fast-property receiver doesn't find anything,
try a stub cache lookup before going into the runtime. This is much
faster for properties loaded from the receiver's prototype chain.

BUG=chromium:650236

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

Revert of [stubs] Don't unconditionally canonicalize in ChangeFloat64ToTagged. (patchset #2 id:20001 of https://codereview.chromium.org/2380543002/ )

Reason for revert:
Tanks ai-astar in Kraken pretty badly (some deopt loop).

Original issue's description:
> [stubs] Don't unconditionally canonicalize in ChangeFloat64ToTagged.
>
> 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
>
> Committed: https://crrev.com/06eef6e6d8199df8317df8469d767092472f3fe0
> Cr-Commit-Position: refs/heads/master@{#39804}

TBR=verwaest@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5268

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

BUG=

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

[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}