This is a reland of part of
https://chromium-review.googlesource.com/c/v8/v8/+/1397664.

It drops the explicit fni_.Infer() call after parsing arrow functions. We'll
want to avoid inferring if the arrow function is an argument to a function
call.

It also avoids adding the single argument of "name => " to the inferred name.

Bug: chromium:916975
Change-Id: I96a934408113483d73eba14073fe21e8cfe2ada6
Reviewed-on: https://chromium-review.googlesource.com/c/1397665
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58613}

This reverts commit 3411e7c3.

Reason for revert: Breaks test expecations - https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/260731

Original change's description:
> [parser] Create arrow function scopes while parsing the head
> 
> This simplifies NextArrowFunctionInfo, allows us to Scope::Snapshot::Reparent
> directly rather than moving it, and allows us to skip reparenting in the simple
> parameter arrow function cases.
> 
> This CL additionally fixes arrow function name inferring.
> 
> Change-Id: Ie3e5ea778f3d7b84b2a10d4f4ff73931cfc9384a
> Reviewed-on: https://chromium-review.googlesource.com/c/1386147
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58405}

TBR=ishell@chromium.org,verwaest@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: I8f31b96f844f0673364bf435fa6c809e40d62fa3
Reviewed-on: https://chromium-review.googlesource.com/c/1388541Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58446}

This simplifies NextArrowFunctionInfo, allows us to Scope::Snapshot::Reparent
directly rather than moving it, and allows us to skip reparenting in the simple
parameter arrow function cases.

This CL additionally fixes arrow function name inferring.

Change-Id: Ie3e5ea778f3d7b84b2a10d4f4ff73931cfc9384a
Reviewed-on: https://chromium-review.googlesource.com/c/1386147Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58405}

Old instrumentation was designed to collect promise creation stack and
promise scheduled stack together. In DevTools for last 6 months we
show only creation stack for promises. We got strong support from users
for new model. Now we can drop support for scheduled stacks and
simplify implementation.

New promise instrumentation is straightforward:
- we send kDebugPromiseThen when promise is created by .then call,
- we send kDebugPromiseCatch when promise is created by .catch call,
- we send kDebugWillHandle before chained callback and kDebugDidHandle
  after chained callback,
- and we send separate kDebugAsyncFunctionPromiseCreated for internal
  promise inside async await function.

Advantages:
- we reduce amount of captured stacks (we do not capture stack for
  promise that constructed not by .then or .catch),
- we can consider async task related to .then and .catch as one shot
  since chained callback is executed once,
- on V8 side we can implement required instrumentation using only
  promise hooks,

Disadvantage:
- see await-promise test, sometimes scheduled stack was useful since we
  add catch handler in native code,

Implementation details:
- on kInit promise hook we need to figure out why promise was created.
  We analyze builtin functions until first user defined function on
  current stack. If there is kAsyncFunctionPromiseCreate function then
  we send kDebugAsyncFunctionPromiseCreated event. If there is
  kPromiseThen or kPromiseCatch then only if this function is bottom
  builtin function we send corresponded event to inspector. We need it
  because Promise.all internally calls .then and in this case we have
  Promise.all and Promise.then on stack at the same time and we do not
  need to report this internally created promise to inspector.

Bug: chromium:778796
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
Reviewed-on: https://chromium-review.googlesource.com/765208
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49553}

Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.

BUG=v8:6189
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2868493002
Cr-Original-Commit-Position: refs/heads/master@{#45198}
Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a
Review-Url: https://codereview.chromium.org/2868493002
Cr-Commit-Position: refs/heads/master@{#45266}

Revert of [inspector] use creation stack trace as parent for async call chains (patchset #2 id:20001 of https://codereview.chromium.org/2868493002/ )

Reason for revert:
CHECK is too strict.

Original issue's description:
> [inspector] use creation stack trace as parent for async call chains
>
> Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
> For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2868493002
> Cr-Commit-Position: refs/heads/master@{#45198}
> Committed: https://chromium.googlesource.com/v8/v8/+/e118462f18a862df81a04486e13dd62997cbfc5a

TBR=dgozman@chromium.org,alexclarke@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6189

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

Creation stack trace points to the place where callback was actually chained, scheduled points where parent promise was resolved.
For async tasks without creation stack (e.g. setTimeout) we continue to use scheduled as creation since usually they are the same.

BUG=v8:6189
R=dgozman@chromium.org

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

With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained.
At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback:

foo2 (test.js:14:2)
-- Promise.resolve (test.js:29:14)--
-- Promise.resolve (test.js:28:14)--
promiseThen (test.js:30:2)

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

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

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

... which were done after the promise has been resolved.

Goal of this CL - change promise instrumentation to support better callbacks, chained after promise resolution and prepare instrumentation for adding new asyncTaskCreated instrumentation.

Instrumentation changes:
- asyncTaskScheduled(recurring) when promise is fulfilled or rejected,
- asyncTaskCancelled when promise is collected (since [1] we can be sure that promise will survive scheduled microtasks).

Minor changes:
- async task type in inspector <-> debugger API transferred by enum instead of string,
- Debug manages async task ids based on promise objects.

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

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

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

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