Torque allows a `weak` keyword on class field declarations. This keyword
is confusing, because it means two completely different things:

1. This field should be included in the weak fields section, meaning the
   field's offset should be in the range [kStartOfWeakFieldsOffset,
   kEndOfWeakFieldsOffset).
2. If a BodyDescriptor is generated for this class, then this field
   should be visited using *custom* weakness semantics
   (IterateCustomWeakPointers, not IterateMaybeObjectPointers).

I propose the following updated behavior, which I think is a bit more
reasonable:

1. To request that the generated BodyDescriptor use custom weakness
   semantics, use a new annotation @customWeakMarking.
2. The weak fields section includes all fields that can be a Weak<T>
   type, plus those annotated with @customWeakMarking.

These new rules require reordering fields in two classes which didn't
already have all of their strong fields adjacent.

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

This reverts commit a3480b55.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview

Original change's description:
> Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"
>
> This is a reland of 7366f6e2
>
> The test that failed after the initial commit was just flaky and has
> been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
>
> Original change's description:
> > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
> >
> > Torque currently generates constants like kStartOfWeakFieldsOffset and
> > kEndOfStrongFieldsOffset, which can be used when writing custom
> > BodyDescriptors. However, these offsets have some potentially confusing
> > behaviors:
> >
> > * They don't take inheritance into account and describe only the fields
> >   defined by the current class itself, so there might be (for example)
> >   strong fields before kStartOfStrongFieldsOffset if they were defined
> >   by a superclass.
> > * kStartOfWeakFieldsOffset points to the first field defined in Torque
> >   using the keyword `weak`, which indicates fields with *custom*
> >   weakness semantics (those that should be visited with
> >   IterateCustomWeakPointers), not those that may contain standard weak
> >   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
> >   like to also rename `weak` to `@customWeak`.)
> >
> > Given that these constants have very low usage and somewhat bizarre
> > semantics, I propose that we remove them. This change does so, and
> > updates the existing usages to either define the required constants
> > directly in C++ or not use them. I know that defining these constants in
> > C++ is more brittle, but I think that brittle and clear is better than
> > automatic and incomprehensible.
> >
> > Bug: v8:7793
> > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Cr-Commit-Position: refs/heads/main@{#77411}
>
> Bug: v8:7793
> Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77688}

Bug: v8:7793
Change-Id: I7b9667268901b7aef85a95832d40860056e61050
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77689}

This is a reland of 7366f6e2

The test that failed after the initial commit was just flaky and has
been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341

Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
>   defined by the current class itself, so there might be (for example)
>   strong fields before kStartOfStrongFieldsOffset if they were defined
>   by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
>   using the keyword `weak`, which indicates fields with *custom*
>   weakness semantics (those that should be visited with
>   IterateCustomWeakPointers), not those that may contain standard weak
>   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
>   like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}

Bug: v8:7793
Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77688}

This is a reland of 45227ffd
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}

This reverts commit 45227ffd.

Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77566}

Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.

Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
   OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
   HeapConstant Factory::zero_string(). However, NumberToString does
   not always produce this string. To avoid regressions, the CL keeps
   the HeapConstant type and changes the runtime and builtin code to
   always produce the canonical "0" string.

A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.

Drive-by fix: a few minor Torque issues that came up.

Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}

This reverts commit 7366f6e2.

Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties

Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
>   defined by the current class itself, so there might be (for example)
>   strong fields before kStartOfStrongFieldsOffset if they were defined
>   by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
>   using the keyword `weak`, which indicates fields with *custom*
>   weakness semantics (those that should be visited with
>   IterateCustomWeakPointers), not those that may contain standard weak
>   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
>   like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}

Bug: v8:7793
Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77415}

Torque currently generates constants like kStartOfWeakFieldsOffset and
kEndOfStrongFieldsOffset, which can be used when writing custom
BodyDescriptors. However, these offsets have some potentially confusing
behaviors:

* They don't take inheritance into account and describe only the fields
  defined by the current class itself, so there might be (for example)
  strong fields before kStartOfStrongFieldsOffset if they were defined
  by a superclass.
* kStartOfWeakFieldsOffset points to the first field defined in Torque
  using the keyword `weak`, which indicates fields with *custom*
  weakness semantics (those that should be visited with
  IterateCustomWeakPointers), not those that may contain standard weak
  pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
  like to also rename `weak` to `@customWeak`.)

Given that these constants have very low usage and somewhat bizarre
semantics, I propose that we remove them. This change does so, and
updates the existing usages to either define the required constants
directly in C++ or not use them. I know that defining these constants in
C++ is more brittle, but I think that brittle and clear is better than
automatic and incomprehensible.

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

Currently, it is possible to declare macros, builtins, etc., without
specifying a return type, in which case the return type is treated as
void. This is confusing; the code is more clear if we require the return
type to be specified.

Aside from src/torque, this change is almost entirely just adding
`: void` until the compiler is happy. However, two intrinsics in
src/builtins/torque-internal.tq have been corrected to declare an
appropriate return type. Those two intrinsics were only used in code
generated within the compiler after the type-checking phase, so we never
noticed that their return types were declared incorrectly.

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

Currently, some ScopeInfo fields are defined as indexed fields with a
length of either one or zero, because the field might be present or it
might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 ,
this strategy is not sustainable and we need a better way to represent
optional fields so that we don't have to pass zero when accessing their
only element. This change is a proposal to fix that problem.

Syntax:

I'm proposing using a question mark because TypeScript does, and Torque
syntax looks somewhat like TypeScript. I don't feel strongly about this
though, and I'm open to other suggestions.
  field_name?[condition_expression]: FieldType;

Internal Torque compiler representation:

Internally, I've updated the Torque compiler to still treat these fields
as indexed, but with an extra flag saying they're optional. When getting
a LocationReference for a field access expression on an optional field,
Torque produces a Slice like it would for any other indexed field and
subsequently calls AtIndex(0) to get a Reference.

AtIndex can crash the process if the index is out of bounds (which is
good), so some other parts of the Torque compiler need minor adjustments
so that it doesn't take references to optional fields unless it actually
needs them.

Initialization:

This proposal doesn't include any changes to initialization logic, so an
optional field can still be initialized using '...' and an iterator.
Perhaps we could introduce an Optional<T> struct for prettier
initialization in a future change.

Bug: v8:7793
Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73018}

This change adds a new abstract type Lazy<T> which can be used to
interoperate with CSA code that uses LazyNode. This new type has special
code-generation rules because its generated type is not TNode<...> but
std::function<TNode<...>()>. Torque code can do nothing with this type
except pass it around, but passing it to the CSA function RunLazy is an
easy way to execute the std::function and get back a normal value.
Torque code can also create Lazy<T> values using the intrinsic function
%MakeLazy, which takes the name of a macro as its first parameter,
followed by arguments to that macro which will be passed when the
LazyNode is evaluated. We use the macro's name because the language
doesn't support taking references to macros, and implementing such a
feature would be complicated.

Bug: v8:7793
Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72964}

Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI

Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.

Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).

Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}

Currently, all runtime C++ code generated for Torque macros all goes
into a single .cc file and corresponding header. This is simple, but
limits how we can use that generated code. For example, field accessors
are generally expected to be inlinable at compilation time (not relying
on LTO).

This change updates the Torque compiler to output runtime C++ code into
the same *-tq-inl.inc files that contain implementations of member
functions for generated classes. All Torque macros transitively called
from the top-level macros are included in the same file, to avoid any
need for these generated files to #include each other. These macros are
emitted within per-file namespaces to avoid multiple-definition build
failures.

Bug: v8:7793
Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71664}

Port String::Flatten to Torque (using a fast C call for the
non-allocating part) and provide fast and easy access to sequential
string data in Torque: GetStringData() flattens if necessary and
computes slices that allow direct access.

Applications: String.prototype.replaceAll, String.prototype.endsWith,
  and String.prototype.beginsWith now use GetStringData() and direct
  slice access instead of the slow StringCharCodeAt and they no
  longer bail out to the runtime for flattening.

Drive-by changes:
  - Expose String instance type bits as bitfields and enums in Torque.
  - Fix method lookup in Torque to include superclass methods.
  - Use char8 and char16 types in more places.
  - Allow fast C calls with void return type.
  - Add Torque macros to create subslices.
  - Add no-GC scopes to runtime functions loading external string data.


Bug: v8:7793
Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71611}

With this change, there are const and mutable version of slices, in
analogy to const and mutable references, which we already have.
A const slice as a readonly view into memory, it doesn't mean that
nobody else has a writable view on it.

An array field in a Torque class produces const slices if it is declared
as const.

Due to limitations in the Torque type system, mutable slices are not
a subtype of const slices of the same type.

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

Drive-by Torque changes:
  - kSize can be non-aligned, use SizeFor() instead for map allocation.
  - Factory functions use Torque-generated setters directly to work even
    if they are shadowed.
  - Allow class generation in the presence of custom weak fields, this
    was supported already.


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

This CL lets Torque generate the Context C++ class and BodyDescriptor
for Context.
This requires two Torque changes:

- Allow @generateBodyDescriptor on @abstract classes, since all Context
  classes share the same BodyDescriptor.

- Add a new annotation @relaxedWrite, which makes C++ setters
  use WRITE_RELAXED_FIELD instead of WRITE_FIELD.
  Attention: As a side-effect, this CL disables using
    WRITE_RELAXED_FIELD by default for all non-array fields. If this
    causes problems, we should manually add @relaxedWrite to the
    corresponding fields.

Bug: v8:7793

Change-Id: I735b310bcb36a3612d86c22efa9c0bfc108d4ca6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529453
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71123}

Drive-by fixes:
 - Use constexpr types to determine C++ type names.
 - Fix factory constructors to not skip write barriers in old generation.

Change-Id: I0ebbfd56c06ad41d02836fb48531ae7eded166bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400994Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70921}

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}

Originally, the Torque-generated verifier for a field with type
Undefined|Zero|NonNullForeign would check `f.IsUndefined() || f.IsZero()
|| f.IsNonNullForeign()`. At some point, we changed Torque so that it
now generates the much weaker `f.IsOddball() || f.IsSmi() ||
f.IsForeign()`. This change returns the verifiers to their initial
precision. Mostly we can use the names of abstract types to build up the
correct type check expression, but a few abstract types like
PodArrayOfWasmValueType have no way that we can tell them apart from
their parent type at runtime. It would be confusing to have a function
Object::IsPodArrayOfWasmValueType which actually just checks whether the
object is a ByteArray, so this change introduces a new annotation which
allows abstract type declarations to state that they should use their
parent type during verification.

This change also adds new test cases to help avoid future regressions of
this logic.

Bug: v8:7793
Change-Id: Ie5046d742fd45e0e0f6c2ba387d909e9f2ac6df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469960Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70698}

Currently, when accessing a field that doesn't have a constant offset,
Torque emits code to compute each preceding indexed field's length and
add them all together. This works, but such code can get super long if a
class has many indexed fields, and especially if the length expressions
of some indexed fields refer to other indexed fields. We'd like the
output of the new C++ backend to be short enough to go in inline headers
which will be included in many compilation units.

This change attempts to reorganize the code so that the computation of
each length expression can only be emitted exactly once. This only
shortens the generated C++ code; the resulting TurboFan output should be
identical. There are two main parts:
1. For each indexed field, we already generate a macro that can get a
   Slice referring to that field. Update these macros to not use the dot
   operator on that field. Using the dot operator on the predecessor
   field is allowed.
2. Update the dot operator for indexed fields to emit a call to the
   macro from step 1.

This sort of reverses the dependency added by the previous change
https://crrev.com/c/2429566 : rather than the slice macros depending on
the dot operator, this change makes the dot operator depend on the slice
macros.

The overall torque_generated directory shrinks by under 1% with this
change, but the runtime_macros.cc file (which should eventually become
inline headers) shrinks by 24%. More to the point, this change keeps
runtime_macros.cc from ballooning out of control when we add a
work-in-progress Torque definition for ScopeInfo
( https://crrev.com/c/2357758 ).

Bug: v8:7793
Change-Id: I989dda9c3666f1a49281fef03acb35baebb5b63a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432070Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70325}

This change adds a new code generator, which supports a subset of the
instructions supported by the existing CSAGenerator, and instead of
generating CSA it generates runtime C++ code. The new generator is used
to generate a set of Torque macros that return slices to indexed fields.
These new macros should be sufficient to eventually support
Torque-generated field accessors, BodyDescriptors, verifier functions,
and postmortem field inspection in debug_helper.

Bug: v8:7793
Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70313}

This enables defining abstract type subtypes of classes
with constexpr version, which in turn is useful to model
custom C++ subclasses.

Bug: v8:7793
Change-Id: I07dcb62121afdddfbe2c78ecc870afcb11800c19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412180
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69982}

e.g. the following is now valid Torque code:

  macro TestA(implicit c: Context)() {}

  macro TestB(): bool {
    return TestA();
  }

This is handy for more flexible usage of generics that may or may not
use implicit parameters deep inside their specializations.

Note that this change doesn't change the fundamental rigor (or lack
thereof) around checking the usage of implicit parameters, which
already do not require '_' before their parameter identifier if
unused. It just silences errors in cases where a call site doesn't
implicitly pass a parameter that ultimately doesn't have a use site
and adds meaningful error messages in the case that it does.

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

Change-Id: I4f610400eab6e24fb7eb06465ca9abc63d20fdb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182474Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67593}

Without the added header some GCC compilers might produce this error:

error: 'ceil' is not a member of 'std'

Change-Id: I4fc784725c904adc58919a766671e37c9aca7ecb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2181774
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67563}

Summary of changes:

- GC visitors no longer rely on superclass visitors, but instead visit
  everything themselves. This enables generating better code.
- Try to match simple body descriptors to reduce the amount of generated
  code.
- Turn SizeFor(instance) into an AllocatedSize() method.
- Remove the special handling of resizable object sizes from Torque
  and instead overwrite AllocatedSize in classes that need special
  handling in C++.
- Split the visitor id lists depending on whether the class has pointer
  fields.
- Turn Torque-generated body descriptors into an .inc file to
  simplify includes.
- Fix generated size functions to properly align the size.
- Generate GC visitors (and C++ class definitions) for all string
  classes and FixedArray, WeakFixedArray, and WeakArrayList.
- Store generated instance types in Torque class types. This is only
  used to determine if a type has a single instance type in this CL.

Bug: v8:7793
Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67542}

... and bottlenecks for C++, CSA, Torque, TurboFan and hand-written
assembly.

Bug: v8:10391
Change-Id: I62f8c6f9c934b2cd492e550b7c25f1078c2c6a71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134140
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67479}

Bug: v8:10404, v8:7793
Change-Id: I7ed5fc790bd97af0dd3671669779e416101731ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162877
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67435}

This is a reland of 80843eda

Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
> 
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
>    are packed within Smi values, which previously would have required a
>    separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
>    a branch or the left-hand side of a Word32Equals is based on a 64-bit
>    shift-and-mask operation which has been truncated to 32 bits, as is
>    the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
>    Word64And operation added by step 1.
> 
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}

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

This reverts commit 80843eda.

Reason for revert: Causes compilation failure on macs

https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?


Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
> 
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
>    are packed within Smi values, which previously would have required a
>    separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
>    a branch or the left-hand side of a Word32Equals is based on a 64-bit
>    shift-and-mask operation which has been truncated to 32 bits, as is
>    the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
>    Word64And operation added by step 1.
> 
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}

TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org

Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67291}

This change:
1. Updates the Torque compiler to allow direct access to bitfields that
   are packed within Smi values, which previously would have required a
   separate untagging step,
2. Updates JSRegExpStringIterator to represent its flags in Torque,
3. Adds reduction cases in MachineOperatorReducer for when the input to
   a branch or the left-hand side of a Word32Equals is based on a 64-bit
   shift-and-mask operation which has been truncated to 32 bits, as is
   the case in the code generated by step 1, and
4. Adds a reduction case in MachineOperatorReducer to remove an extra
   Word64And operation added by step 1.

Bug: v8:7793
Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67290}

To enable this, the following changes were necessary:
- Fix generation of accessors with MaybeObject type
  and a bunch of include problems.
- Torque-generated C++ classes now have a constructor that can allow
  Smi values to enable a hack currently used for the DescriptorArray.


Bug: v8:7793 v8:8983
Change-Id: If6e35db99199a0e2afd2698af3d84777d6d0b18f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108036
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67247}

The two refactorings are somewhat orthogonal, but intersect at the
class and instance type list generation, which is why it's easier to
put them in one CL.

For the removal of HasIndexedField, the removal is motivated by the
fact that is no longer necessary, and that using a flag to store this
kind of information is hacky.

For the class list changes, this is a cleanup in that we no longer
generate third-order macros, but instead normal macro lists.
There is a functional change and bug-fix in that we no longer include
abstract classes in lists that refer to instance types or maps. It's
still somewhat broken though, so I can't test abstract internal classes
yet, though. Coming in a follow-up CL.

TBR=ulan@chromium.org

Bug: v8:7793
Change-Id: Ided8591370570ca3810d7991f53177ca32e03048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108034
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67056}

In the runtime, we always had a convention to use int-typed accessors
for Smi fields. For Torque-generated classes, we kept them Smi-typed
but then added int wrappers around that.
This CL makes Torque generate int-typed accessors directly, removing the
need for these wrappers.

TBR=hpayer@chromium.org

Bug: v8:7793
Change-Id: I348e1d96295c9676fafda32b7d49088848527f89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66760}

- Allow type expression for abstract type supertypes.
  For consistency, and ease of implementation, also allow this for enums.
- Allow subtyping of structs. This requires changing all places where we
  checked for struct types and instead check if we have a subtype of a
  struct type.
- This allows defining two subtypes of the Reference<T> struct for
  mutable and constant references. Mutable references are a subtype of
  constant references.
- &T desugars to MutableReference<T>
  const &T desugars to ConstReference<T>
- A const field of a class produces a constant reference.
  A const field of a mutable reference to a struct is const.
  A mutable field of a const reference to a struct is const.
- It is possible to assign a new struct value to a mutable reference to
  a struct, even if the struct contains const fields. This is analogous
  to allowing assignments of let-bound structs with constant fields.

Not in this CL:
- A notion of const slices.
- Applying const to appropriate class fields.

Bug: v8:7793
Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66759}

In the process:

* Augment C++-generated Torque classes with SizeFor methods to
  calculate size of instances.

* Add a new "@generateBodyDescriptor" annotation that causes Torque to
  generate C++ BodyDescriptors code that can be used to visit objects
  compatible with existing V8 mechanisms, e.g. GC

* Fully automate C++ macro machinery so that adding non-extern Torque
  class doesn't require any C++ changes, including ensuring generation
  of instance types and proper boilerplate for validators and
  printers.

* Make handling of @export a true annotation, allowing the modifier to
  be used on class declarations.

* Add functionality such that classes with the @export annotation are
  available to be used from C++. Field accessors for exported classes
  are public and factory methods are generated to create instances of
  the objects from C++.

* Change the Torque compiler such that Non-exported classes implicitly
  have the @generateBodyDescriptor annotation added and causes both
  verifiers and printers to be generated.

* Switch non-extern Torque classes from using existing Struct-based
  machinery to being first-class classes that support more existing
  Torque class features.

Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}

This reverts commit 4dc1fb4e.

Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.

Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea96.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> >    is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> >    occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> >    code for IncBlockCounter match with what was generated before this
> >    change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> >    API. The format matches existing bitfields but with an offset value
> >    that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}

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

Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}

This reverts commit e5e4ea96.

Reason for revert: mysterious performance regression chromium:1052756

Original change's description:
> [torque] Support bitfield structs stored within Smis
>
> This change moves the definition of the bits stored in DebugInfo::flags
> to Torque, and updates the only Torque usage of that field to use more
> natural syntax. This is intended as an example of common patterns found
> in various other classes. Several supporting changes are required:
>
> 1. Add a new type representing a bitfield struct stored within a Smi. It
>    is currently called SmiTagged, but I'm open to suggestions.
> 2. Add an enum-style output for Torque bitfield structs whose bitfields
>    occupy only one bit each.
> 3. Add a new case to MachineOperatorReducer that makes the generated
>    code for IncBlockCounter match with what was generated before this
>    change.
> 4. Add support for reporting these bitfields in the postmortem debugging
>    API. The format matches existing bitfields but with an offset value
>    that includes the SMI shift size.
>
> Bug: v8:7793
> Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66182}

Bug: chromium:1052756, v8:7793
Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66349}

This allows CoverageInfo to be distinguished from other kinds of
FixedArray at runtime. I also updated it to use untagged data since it
only stores ints, since that seems like the generally right thing to do
(even though I doubt anybody allocates enough of these to notice the
reduced GC work).

Related Torque changes:
- Allow structs containing untagged data to be used as class fields.
  This requires classifying them into the tagged or untagged sections of
  the class layout, and checking that their alignment requirements are
  met when stored in a packed array.
- Generate a struct containing struct field offsets, so we can ensure
  that the layouts defined in Torque and C++ code match. Of course it
  would be nice to generate a lot more (indexed accessors, synchronized
  accessors, GC visitors, etc.), but we can't do it all at once.

Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66318}