• Nico Hartmann's avatar
    Revert "Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"" · 6a3dc05f
    Nico Hartmann authored
    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: 's avatarNico 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}
    6a3dc05f
implementation-visitor.cc 211 KB