This is a reland of 94958172

Original change's description:
> [torque] Get rid of @noVerifier annotation
>
> As one small step toward reducing annotations, I propose that all
> classes get generated verifiers unless they've opted out of C++ class
> generation via @doNotGenerateCppClass, and that generated verifiers
> always verify every Torque-defined field. If a generated verifier is
> incorrect, such as for JSFunction or DataHandler, we can just avoid
> calling it and hand-code the verification.
>
> Bug: v8:7793
> Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77145}

Bug: v8:7793
Change-Id: I3da34705bf9fc2b1886161f8f59c7275583f7fc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194812
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77168}

This reverts commit 94958172.

Reason for revert: Breaks arm/arm64 ports, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/30120/blamelist

Original change's description:
> [torque] Get rid of @noVerifier annotation
>
> As one small step toward reducing annotations, I propose that all
> classes get generated verifiers unless they've opted out of C++ class
> generation via @doNotGenerateCppClass, and that generated verifiers
> always verify every Torque-defined field. If a generated verifier is
> incorrect, such as for JSFunction or DataHandler, we can just avoid
> calling it and hand-code the verification.
>
> Bug: v8:7793
> Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77145}

Bug: v8:7793
Change-Id: I56da8a9726d23470e927be1be5e7bcede1399861
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194262
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77146}

As one small step toward reducing annotations, I propose that all
classes get generated verifiers unless they've opted out of C++ class
generation via @doNotGenerateCppClass, and that generated verifiers
always verify every Torque-defined field. If a generated verifier is
incorrect, such as for JSFunction or DataHandler, we can just avoid
calling it and hand-code the verification.

Bug: v8:7793
Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77145}

Class Constructors are special, because they are callable but [[Call]]
raises an exception. Instead of checking if a JS function is a class
constructor for every JS function call, this CL adds a new instance
type for class constructors.
This way we can use a fast instance type range check for the common
case, and only check for class constructors in the uncommon case were
a class constructor is called and when we need to raise an exception.

Change-Id: Ic6fdd9829722d05559fdfd01f6100c61873a0872
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186434Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77140}

Most Torque-defined extern classes already use CPP class generation. As
Nico pointed out in [1], it would be nice to convert the remaining
classes and remove this option. This change converts most of those
remaining classes. I know that the future of Torque-defined classes is a
subject of some debate right now, but I think that it's worth doing a
few mechanical changes to reduce the existing variety of options. A
couple of minor fixes in the Torque compiler were required so that it
generates correct code for shapes.

[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#

Bug: v8:8952
Change-Id: I7e6087153a18d6ee80e67926793e8ba8e01d501e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015666Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#76586}

Since most Torque-defined extern classes use @generateCppClass, it makes
more sense to instead annotate the small number that don't. This is part
of the cleanup work that Nico recommended in [1].

Classes that still have to opt out:

- Those that can be converted by https://crrev.com/c/3015666
- HeapObject: sort of special since it's the root of the inheritance
  hierarchy. Generated code would include two declarations that don't
  compile until HeapObject is defined:
    bool IsHeapObject_NonInline(HeapObject o);
    explicit TorqueGeneratedHeapObject(
        Address ptr, HeapObject::AllowInlineSmiStorage allow_smi);
- SmallOrdered*: these classes use templates on the C++ side, which is
  not currently representable in Torque.
- SwissNameDictionary: according to a comment, the Torque generation for
  this class is incorrect. I haven't investigated further.

Drive-by fix: make the Torque formatter keep LF on Windows rather than
writing CRLF.

[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#

Bug: v8:8952
Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75841}

The code and prototype_or_initial_map fields are marked as weak in the
torque definition of JSFunction. Given we don't have any annotations
that generate BodyDescriptors or the C++ class specifying weak there
didn't reflect in the actual C++ implementation.

In the C++ implementation we were treating those as strong pointers
and the rest of the code also expects them as strong pointers and
doesn't actually deal with cleared weak references.

Since JSFunction's header doesn't have any weak references we can just
fallback to JSObject::BodyDescriptor that iterates through all header
fields and the other JSObject fields as strong pointers. This is what
was happening because JSFunction didn't have a body descriptor and
we were falling back to JSObject::BodyDescriptor

So this is a clean up CL to avoid confusion. There shouldn't be
any change in behaviour.

So this CL basically:
1. Drops weak from the torque definition to match with implementation
2. Changes JSFunction::BodyDescriptor to JSObject::BodyDescriptor when
iterating over objects to be consistent with other JSObjects with
strong pointers.

Change-Id: I7c3e49f1759164a0f2517b3d5b8d0e5169b025ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2987827Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75387}

This CL adds
- CodeT type - an alias for CodeDataContainer or Code depending on
  whether the v8_enable_external_code_space is enabled or not,
- a set of conversion functions from CodeT to Code or CodeDataContainer
  and back (both in C++ and CodeStubAssembler),
- masm support for calling/tailcalling via CallDataContainer which
  contain the code entry point address,
- masm support for calling/tailcalling via CodeT.

Bug: v8:11880
Change-Id: Ib36f4c6db69ec49aaea29412647e59ada95da19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967463
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75207}

This allows the JSFunctionOrBoundFunction instance type range to no
longer be stuck at the last of the JSObject instance type range. This
will be useful in the future where we extend the function instance
types and include them in fast protector cell checks.

Bug: v8:11256
Change-Id: I955991576b3cca76b10f76c87748016fe527e3d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595275Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71826}

This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:

- torque-generated/src/objects/foo-tq.inc
  An include file (no proper header) to be included in src/objects/foo.h
  containing the Torque-generated C++ class definition.

- torque-generated/src/objects/foo-tq-inl.inc
  An include file (no proper header) to be included in
  src/objects/foo-inl.h containing inline function definitions.

- torque-generated/src/objects/foo-tq.cc
  A source file including src/objects/foo-inl.h that contains non-inline
  function definitions.

Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
  splitting objects.h
- Moving a definition to Torque keeps everything in the same place
  from a C++ viewpoint, including a fully Torque-generated C++ class
  definition.
- The Torque-generated include files do not need to be independent
  headers, necessary includes or forward declarations can just be added
  to the headers that include them.

Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.


Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}