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}

Most Torque-defined extern classes already use @generateCppClass. 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.

Changes that don't exactly follow the usual pattern:
1. BigIntBase, MutableBigInt: we can define these without a body, and
   then Torque treats them as "really external" rather than "kind of
   external, but with some Torque-generated parts".
2. RegExpMatchInfo: moved its inline functions into a separate file,
   which the generated -tq.cc file requires.

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

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

This change enables automatic generation of Cast<> operators for
classes that are defined in Torque.

* Cast<> macros are generated for all classes that are defined in
  Torque code that are neither shapes nor marked with a new
  @doNotGenerateCast annotation.

* Implicitly generated Cast macros simply call through to an
  internally-defined "DownCastForTorqueClass" macro that implements
  the cast using one of three strategies for efficiency. If the class
  has subclasses (i.e. a range of instance types including subtypes),
  the DownCastForTorqueClass checks for inclusion in the instance type
  range. If the class has a single instance type (i.e. no subclasses),
  then either 1) a map check is used if the class has a globally-
  defined map constant or 2) an equality check for the instance type
  is used.

* Added new intrinsics to introspect class information, e.g. fetching
  instance type ranges for a class, accessing the globally-defined map
  for a class.

* Removed a whole pile of existing explicit Cast<> operators that are
  no longer needed because of the implicitly generated Cast<> macros.

* Added tests for the new Cast<> implementations.

Bug: v8:7793
Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68478}

This makes it obvious that methods are actually macros.
Also, in the future, we might allow methods that are actually builtins.

Bug: v8:7793
Change-Id: Ib641c4b5a222b27c67aa0c31fd3611ed4a11842c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967330Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65455}

This creates a .tq file in src/objects for each src/objects/*.h file
with Torque-defined classes and moves the object definitions and
corresponding helpers/macros there.
In addition, we create files convert.tq and cast.tq in src/builtins
to move the casts and conversions to.

Since Torque-generated .cc files end up as .o files in the same
directory, there cannot be two .tq files of the same name. Thus it
was necessary to rename src/builtins/arguments.tq and
src/builtins/string.tq to not clash with the new files in src/objects.

This is a mechanical change that only moves code.

Design doc: http://doc/1fh4OUMjQMnQdJm3aiAPXQUNdgbQugkRGdJzDh8hmyzk

Bug: v8:9861 v8:9810 v8:7793
Change-Id: I9c54cb50f32b9ae0fb41752199515133eb59ea5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910100Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64892}