1. 27 Jan, 2022 1 commit
  2. 26 Jan, 2022 1 commit
  3. 25 Jan, 2022 1 commit
  4. 17 Jan, 2022 1 commit
  5. 10 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Capture stack trace only once for JSError objects. · 765ca6a0
      Benedikt Meurer authored
      When creating a new JSError object (or using the non-standard API
      `Error.captureStackTrace`) V8 would previously capture the "simple stack
      trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
      standard `error.stack` property, and if the inspector was active also
      capture the "detailed stack trace" (as FixedArray of StackFrameInfo
      instances). This turns out to be quite a lot of overhead, both in terms
      of execution time as well as memory pressure, especially since the
      information needed for the inspector is a proper subset of the
      information needed by `error.stack`.
      
      So this CL addresses the above issue by capturing only the "simple stack
      trace" (in the common case) and computing the "detailed stack trace"
      from the "simple stack trace" when on demand. This is accomplished by
      introducing a new ErrorStackData container that is used to store the
      stack trace information on JSErrors when the inspector is active. When
      capturing stack trace for a JSError object while the inspector is
      active, we take the maximum of the program controlled stack trace limit
      and the inspector requested stack trace limit, and memorize the program
      controlled stack trace limit for later formatting (to ensure that the
      presence of the inspector is not observable by the program).
      
      On the `standalone.js` benchmark from crbug.com/1283162 (with the
      default max call stack size of 200) we reduce execution time by around
      16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
      regression in crbug.com/1280831), we are 6% faster now.
      
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Bug: chromium:1280831, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Fixed: chromium:1283162
      Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78542}
      765ca6a0
  6. 15 Dec, 2021 1 commit
  7. 14 Dec, 2021 3 commits
  8. 30 Nov, 2021 1 commit
  9. 15 Nov, 2021 1 commit
  10. 04 Nov, 2021 1 commit
    • Jakob Gruber's avatar
      [string] Micro-optimize String::Flatten · 4593f3c6
      Jakob Gruber authored
      - Use a StringShape instead of repeatedly querying type.
      - Add a shortcut for already-flat strings.
      - Unhandlify where possible (all except SlowFlatten).
      - Mark String::Flatten and StringShape methods V8_INLINE.
      - Add a specialized ConsString::IsFlat overload.
      
      Drive-by: Various (add const, remove this->, helper methods).
      
      Bug: v8:12195
      Change-Id: If20df12bc29c29cff2005fdc9bd826ed9f303463
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259527
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77701}
      4593f3c6
  11. 03 Nov, 2021 3 commits
    • Dominik Inführ's avatar
      [heap, objects] NativeContext::retained_maps might be uninitialized · 45adcb7c
      Dominik Inführ authored
      When a GC happens during context deserialization,
      NativeContext::retained_maps might be uninitialized and not store a
      WeakArrayList but Smi 0.
      
      Bug: v8:12198
      Change-Id: I03c1dfaa013c47907af67bb13b9277d67ca5ffae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259662Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77692}
      45adcb7c
    • 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
  12. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored
      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: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  13. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored
      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}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  14. 26 Oct, 2021 1 commit
  15. 19 Oct, 2021 1 commit
  16. 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
  17. 11 Oct, 2021 2 commits
  18. 08 Oct, 2021 1 commit
  19. 07 Oct, 2021 1 commit
  20. 30 Sep, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Get rid of @noVerifier annotation" · 07d82db1
      Seth Brenith authored
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77168}
      07d82db1
  21. 29 Sep, 2021 4 commits
  22. 28 Sep, 2021 1 commit
  23. 14 Sep, 2021 2 commits
  24. 01 Sep, 2021 1 commit
  25. 30 Aug, 2021 1 commit
  26. 09 Aug, 2021 2 commits
  27. 20 Jul, 2021 1 commit
    • Seth Brenith's avatar
      [cleanup] Use @generateCppClass on more classes · 334b94e1
      Seth Brenith authored
      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: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#75817}
      334b94e1
  28. 19 Jul, 2021 1 commit