1. 10 Jun, 2022 1 commit
  2. 13 May, 2022 1 commit
  3. 06 Dec, 2021 1 commit
  4. 03 Nov, 2021 2 commits
    • 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
    • Seth Brenith's avatar
      Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · a3480b55
      Seth Brenith authored
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77688}
      a3480b55
  5. 15 Oct, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · 6025b260
      Leszek Swirski authored
      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}
      6025b260
    • Seth Brenith's avatar
      [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants · 7366f6e2
      Seth Brenith authored
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77411}
      7366f6e2
  6. 26 Apr, 2021 1 commit
  7. 06 Apr, 2021 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 627b6b2f
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      The original failure was due to a stale Win32 bot. The reland failure
      was due to idempotent task deduplication returning the exact same
      failure. See crbug/1196064
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      No-Try: true
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73795}
      627b6b2f
  8. 05 Apr, 2021 4 commits
    • Shu-yu Guo's avatar
      Revert "Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"" · 562c4251
      Shu-yu Guo authored
      This reverts commit 15c78b45.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32277/overview
      
      Original change's description:
      > Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase"
      >
      > This is a reland of e28dadc2
      >
      > Relanding to see if Win32 rel failures from
      > https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      > were infra flakes. Could not repro on try bots.
      >
      > Original change's description:
      > > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      > >
      > > Currently, IsolateRoot is both the address of the Isolate root and the
      > > base address of the pointer compression reservation. This CL teases the
      > > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      > >
      > > - In addition to V8_COMPRESS_POINTERS, add a
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      > >
      > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      > >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      > >   aliases to GetPtrComprCageBase.
      > >
      > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      > >
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      >
      > No-Try: true
      > Bug: v8:11460
      > Tbr: ishell@chromium.org
      > Tbr: rmcilroy@chromium.org
      > Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73792}
      
      Bug: v8:11460
      Change-Id: Ifee92d622c43a91c15f45ef94ff739237bd2024b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806545
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73793}
      562c4251
    • Shu-yu Guo's avatar
      Reland "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 15c78b45
      Shu-yu Guo authored
      This is a reland of e28dadc2
      
      Relanding to see if Win32 rel failures from
      https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/overview
      were infra flakes. Could not repro on try bots.
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      
      No-Try: true
      Bug: v8:11460
      Tbr: ishell@chromium.org
      Tbr: rmcilroy@chromium.org
      Change-Id: I0a8c3a48999d6737c8c64d2c2703607f14f3fdd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806169Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73792}
      15c78b45
    • Francis McCabe's avatar
      Revert "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" · 07a9ff4d
      Francis McCabe authored
      This reverts commit e28dadc2.
      
      Reason for revert: failed test262 tests;; see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32/32275/steps?succeeded=true&debug=false
      
      Original change's description:
      > [ptr-cage] Rename IsolateRoot to PtrComprCageBase
      >
      > Currently, IsolateRoot is both the address of the Isolate root and the
      > base address of the pointer compression reservation. This CL teases the
      > two uses apart by renaming IsolateRoot to PtrComprCageBase.
      >
      > - In addition to V8_COMPRESS_POINTERS, add a
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      >
      > - Rename GetIsolate* helpers to GetPtrComprCageBase. When
      >   V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
      >   aliases to GetPtrComprCageBase.
      >
      > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      >
      > Bug: v8:11460
      > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Auto-Submit: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73790}
      
      Bug: v8:11460
      Change-Id: I19d0e28194fcdb28e89f129a7694ca3fe29fa17a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806168
      Auto-Submit: Francis McCabe <fgm@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/master@{#73791}
      07a9ff4d
    • Shu-yu Guo's avatar
      [ptr-cage] Rename IsolateRoot to PtrComprCageBase · e28dadc2
      Shu-yu Guo authored
      Currently, IsolateRoot is both the address of the Isolate root and the
      base address of the pointer compression reservation. This CL teases the
      two uses apart by renaming IsolateRoot to PtrComprCageBase.
      
      - In addition to V8_COMPRESS_POINTERS, add a
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE).
      
      - Rename GetIsolate* helpers to GetPtrComprCageBase. When
        V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as
        aliases to GetPtrComprCageBase.
      
      - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment.
      
      Bug: v8:11460
      Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73790}
      e28dadc2
  9. 15 Mar, 2021 1 commit
  10. 12 Mar, 2021 2 commits
  11. 09 Nov, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] allow exported classes with custom C++ class" · bd75b0ba
      Tobias Tebbi authored
      This is a reland of 26f10ecd
      
      Change compared to original CL:
      The deserializer changes StrongDescriptorArray to DescriptorArray.
      Since this CL uses separate BodyDescriptors for the two kinds of
      descriptor arrays, this caused a DCHECK failure when the deserializer
      changes the map while the object is visited from the concurrent marking
      thread. Fix this by disabling the corresponding checks.
      
      
      Original change's description:
      > [torque] allow exported classes with custom C++ class
      >
      > Introduce a new annotation @customCppClass that can be used for
      > non-extern @export classes, that is, generate everything, remove
      > boilerplate from all the internal lists and switches, but allow
      > a custom C++ class, which in turn also allows overwriting the generated
      > print and verify functions.
      >
      > Port DescriptorArray and StrongDescriptorArray as an example.
      >
      > Bug: v8:7793
      > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70989}
      
      Bug: v8:7793
      Change-Id: I7505fb111896991d16d7d113704c8c3676669f34
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526383Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71048}
      bd75b0ba
  12. 05 Nov, 2020 2 commits
  13. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  14. 16 Oct, 2020 1 commit
  15. 07 Oct, 2020 1 commit
  16. 10 Jun, 2020 1 commit
  17. 27 May, 2020 1 commit
  18. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored
      This CL is pretty mechanical; I just iterated through some Torque
      classes making the following changes:
      
      - Use @generateCppClass if it seems easy to
      - Use @generatePrint if the existing printer doesn't do anything special
      - Fix up any imprecise field types
      
      It also includes two minor changes to implementation-visitor:
      
      - Add a new -inl.h file with the things needed for
        torque-generated/class-definitions-tq.cc so we don't need to keep
        changing the compiler when we add @generateCppClass.
      - Avoid emitting incorrect accessors for ExternalPointers. This isn't
        strictly necessary for correctness, as the accessors defined in C++
        already hide the ones inherited from generated code, but it makes me
        feel safer.
      
      Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  19. 04 Mar, 2020 1 commit
  20. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [isolate] Make field getters use a const Isolate* · 42a56e03
      Leszek Swirski authored
      To indicate that the Isolate* in getters might not be a "real" isolate,
      but rather a calculated one from GetIsolateForPtrCompr only used for
      calculating the isolate root, make that function return a const Isolate*
      and change field getters, Object::IsFoo predicates, and related
      functions to all take a const Isolate* instead of an Isolate*
      
      With this change, we can slightly more confidently use Objects that are
      in OffThreadSpace, without having to worry too much about having an
      Isolate* floating around that could accidentally be used.
      
      This is a slight abuse of const semantics, but it allows implicit
      conversion from Isolate* arguments to the const Isolate* parameter.
      
      Bug: v8:7703
      Bug: chromium:1011762
      Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65199}
      42a56e03
  21. 18 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Verify nested struct fields in classes · 88a2d011
      Seth Brenith authored
      As one of several steps involved in supporting struct-valued fields
      within classes, this CL generates type verification code for the data
      contained in those structs.
      
      In order to generate verification code, Torque needs to know about
      struct field offsets and the total size of structs. Those calculations
      are added to StructType itself and the function TypeVisitor::ComputeType
      which initializes the StructType. I repurposed the Field::offset value
      to behave in structs more like it does in classes (it had previously
      indicated the index of a field within a struct, but nobody used that
      value). Overall this works okay, and I think it's less confusing to have
      Field::offset mean the same thing everywhere. However, some struct
      fields have types with unknown size (Field::GetFieldSizeInformation
      fails), so those fields are now marked with offset Field::kInvalidOffset
      to indicate that the structs containing them should not be used within
      class fields or anywhere else that requires packed layout.
      
      Bug: v8:7793
      Change-Id: If2677c8c81efc85e63b4bfb831d818a748427e18
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897247
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65016}
      88a2d011
  22. 15 Nov, 2019 1 commit
  23. 11 Oct, 2019 1 commit
  24. 13 Sep, 2019 1 commit
  25. 15 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use @generateCppClass in some simple cases · 14274bb1
      Seth Brenith authored
      This change is mostly mechanical, but it's worth mentioning a few
      slightly interesting cases:
      - A couple of field definitions didn't match the signedness of their
        corresponding accessors.
      - The generated accessors for Smi data use Smi values directly, but
        usually we want C++ accessors to use ints instead. I added a macro
        that hides the generated Smi accessors and exposes int accessors,
        but we might consider generating int accessors directly.
      - The data held in some fields is described in comments next to the
        accessor definition for those fields. With automatically generated
        accessors, those comments need a new home. In this change I put them
        in the Torque object definition, but I'm open to other suggestions.
      - gen-postmortem-metadata couldn't find updated class definitions after
        they got split across multiple lines, so I changed its matching
        logic. (Ideally debug-support.cc should be a Torque compiler output
        rather than something that involves parsing C++ with regexes, but
        this makes it correctly report subclass relationships for now.)
      - The end offsets generated by Torque were off by one from the values
        that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS.
      
      Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#62719}
      14274bb1
  26. 08 Jul, 2019 1 commit
  27. 03 Jul, 2019 1 commit
  28. 27 Jun, 2019 1 commit
  29. 17 Jun, 2019 2 commits
  30. 23 May, 2019 2 commits
  31. 22 May, 2019 1 commit