This patch implements https://github.com/tc39/proposal-class-fields/pull/269
and makes sure we always throw TypeError when there is invalid private
name access in computed property keys.

Before this patch, private name variables of private fields and methods
are initialized together with computed property keys in the order they
are declared. Accessing undefined private names in the computed property
keys thus fail silently.

After this patch, we initialize the private name variables of private
fields before we initialize the computed property keys, so that invalid
access to private fields in the computed keys can be checked in the IC.
We now also initialize the brand early, so that invalid access to private
methods or accessors in the computed keys throw TypeError during brand
checks - and since these accesses are guarded by brand checks, we can
create the private methods and accessors after the class is
defined, and merge the home object setting with the creation
of the closures.

Bug: v8:8330, v8:9611
Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64225}

A class's fields can appear twice in the class AST, via the properties
array and the synthetised initializer method. This means that the
reindexer can end up visiting the same function literal twice, since the
T in AST is no longer a T but rather a DAG.

Now, we special case the class visitor in the reindexer to avoid these
double visits where appropriate. We know what kinds of fields can be
double visisted, so we don't need a visited set, but we now also have
one for debug builds to verify that each function is visited exactly
once.

Bug: chromium:974627
Change-Id: Ib531becc6e3f3c73f420b5fb49790fe4a2022d65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667003Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62282}

TBR=bmeurer@chromium.org,leszeks@chromium.org

Bug: v8:9247
Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61769}

Fixing clang-tidy warning.

Bug: v8:8015
Change-Id: If9a66df529dc5870f6d5146d9a83d22367ffdc59
Reviewed-on: https://chromium-review.googlesource.com/1224114Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#55883}

Downside: this adds all kinds of weird includes in the .cc files.

(See design doc linked in the bug.)

BUG=v8:5402

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

They're supposed to be stable across several parse passes, so we'll also
store them in the associated SharedFunctionInfos

To achieve this, the PreParser and Parser need to generated the same number of
FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of
class literals.

For regular functions, the function IDs are assigned in the order they occur in
the source. For arrow functions, however, we only know that it's an arrow function
after parsing the parameter list, and so the ID assigned to the arrow function is
larger than the IDs assigned to functions defined in the parameter list. This
implies that we have to reset the function ID counter to before the parameter list
when re-parsing an arrow function. To be able to do this, we store the number of
function literals found in the parameter list of arrow functions as well.

BUG=v8:5589

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