1. 09 Aug, 2022 1 commit
    • Qifan Pan's avatar
      Reland "Reland "[TurboFan] Support BigIntMultiply"" · 25530fd6
      Qifan Pan authored
      This is a reland of commit 30ee0690
      
      Avoid terminating from another thread in unit tests to make the termination of optimized bigint multiplication deterministic on windows
      
      Original change's description:
      > Reland "[TurboFan] Support BigIntMultiply"
      >
      > This is a reland of commit ccde4205
      >
      > Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
      >
      > Original change's description:
      > > [TurboFan] Support BigIntMultiply
      > >
      > > Bug: v8:9407
      > > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
      > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#82140}
      >
      > Bug: v8:9407
      > Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82232}
      
      Bug: v8:9407
      Change-Id: I7d04897f4e8f260aba31dbad55ce1263406473d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819621
      Commit-Queue: Qifan Pan <panq@google.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82304}
      25530fd6
  2. 05 Aug, 2022 2 commits
    • Francis McCabe's avatar
      Revert "Reland "[TurboFan] Support BigIntMultiply"" · 8b63cc9b
      Francis McCabe authored
      This reverts commit 30ee0690.
      
      Reason for revert: breaks something on windows: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/47755/overview
      
      Original change's description:
      > Reland "[TurboFan] Support BigIntMultiply"
      >
      > This is a reland of commit ccde4205
      >
      > Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
      >
      > Original change's description:
      > > [TurboFan] Support BigIntMultiply
      > >
      > > Bug: v8:9407
      > > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
      > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#82140}
      >
      > Bug: v8:9407
      > Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82232}
      
      Bug: v8:9407
      Change-Id: I006ed3770564149ae146c614c3d693de9ec29e41
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812289
      Owners-Override: Francis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Auto-Submit: Francis McCabe <fgm@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#82233}
      8b63cc9b
    • Qifan Pan's avatar
      Reland "[TurboFan] Support BigIntMultiply" · 30ee0690
      Qifan Pan authored
      This is a reland of commit ccde4205
      
      Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
      
      Original change's description:
      > [TurboFan] Support BigIntMultiply
      >
      > Bug: v8:9407
      > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82140}
      
      Bug: v8:9407
      Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82232}
      30ee0690
  3. 03 Aug, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "[TurboFan] Support BigIntMultiply" · 8851a274
      Nico Hartmann authored
      This reverts commit ccde4205.
      
      Reason for revert: Investigating performance regressions
      
      Original change's description:
      > [TurboFan] Support BigIntMultiply
      >
      > Bug: v8:9407
      > Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82140}
      
      Bug: v8:9407
      Change-Id: I21de9fd43df2e043b4019d2bad560329ef0971b4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807584
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#82168}
      8851a274
  4. 02 Aug, 2022 1 commit
  5. 07 Feb, 2022 1 commit
  6. 04 Feb, 2022 1 commit
    • Nico Hartmann's avatar
      Reland "Reland "[Torque] Generalize Torque literals to larger size"" · 362b30eb
      Nico Hartmann authored
      This is a reland of 517ed4ad
      
      Original change's description:
      > Reland "[Torque] Generalize Torque literals to larger size"
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Changes in the reland: Simplified IntegerLiteral to single digit.
      >
      > Bug: v8:7793, chromium:1289282
      > Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78811}
      
      Bug: v8:7793, chromium:1289282
      Change-Id: I7aadc4d2c9494f03eae85e94949c8f4cab7a075c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3437047Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78939}
      362b30eb
  7. 28 Jan, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "Reland "[Torque] Generalize Torque literals to larger size"" · d96934c7
      Nico Hartmann authored
      This reverts commit 517ed4ad.
      
      Reason for revert: There still seems to be an issue on V8 Win msvc related to this CL (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/20568/overview).
      
      Original change's description:
      > Reland "[Torque] Generalize Torque literals to larger size"
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Changes in the reland: Simplified IntegerLiteral to single digit.
      >
      > Bug: v8:7793, chromium:1289282
      > Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78811}
      
      Bug: v8:7793, chromium:1289282
      Change-Id: I818cec9625fbd827a4a30088d8c8b759fb6c50d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424484
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78847}
      d96934c7
  8. 27 Jan, 2022 1 commit
  9. 20 Jan, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "[Torque] Generalize Torque literals to larger size" · 362e265d
      Nico Hartmann authored
      This reverts commit 757830b0.
      
      Reason for revert: Speculatively revert due to a number of
      performance regressions
      
      Original change's description:
      > [Torque] Generalize Torque literals to larger size
      >
      > Previously, literals in Torque were stored as double values, which
      > made it impossible to precisely represent 64 bit integer values.
      > This CL replaces the old literal expression with an integer and
      > floating point literal expression that are unbounded in size. We
      > allow implicit conversion of these literals to arbitary integer
      > and floating point types respectively and insert a corresponding
      > bounds check into generated CSA.
      >
      > Bug: v8:7793
      > Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78671}
      
      Bug: v8:7793
      Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78706}
      362e265d
  10. 18 Jan, 2022 1 commit
  11. 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
  12. 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
  13. 30 Sep, 2021 1 commit
  14. 04 Dec, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] uniform flattening and string access in Torque · 65d2c4b4
      Tobias Tebbi authored
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71611}
      65d2c4b4
  15. 30 Nov, 2020 1 commit
  16. 11 Nov, 2020 1 commit
  17. 17 Aug, 2020 1 commit
    • Z Nguyen-Huu's avatar
      Reland "Improve NumberToString when cache miss and Smi" · 22874998
      Z Nguyen-Huu authored
      This is a reland of 1b35c0fa
      
      Reason for revert: Seems to reliably break a numerics test:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31516
      
      It was really slow and timeout with debug build run this test
      mjsunit/math-exp-precision with --optimize-for-size because we resize
      cache in CSA. Default this to runtime would avoid the timeout.
      
      Also with --optimize-for-size, we don't have enough space to allocate
      full-size cache so avoid to resize cache in this case.
      
      In my local PC, time for this test decreases as follows.
      Before: 52s
      After: 3s
      
      Original change's description:
      > Improve NumberToString when cache miss and Smi
      >
      > Cache miss was handled in runtime before. This change add fast path for
      > Smi in this case.
      >
      > Perf show 30% improvement for the following example.
      > Before 67 ms
      > After 42 ms
      >
      > const start = new Date();
      > const MAX = 1000000;
      > for (var i = 0; i < MAX; i++) {
      >     i.toString();
      > }
      > const end = new Date();
      > console.log("Time :"+ (end-start));
      >
      > Change-Id: I162e9c35f58551ca6a5a0efe79fb7c7b482a8594
      > Bug: v8:10477
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332866
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69362}
      
      Bug: v8:10477
      Change-Id: I892a9007210032640d0bf22e61c8e7ad1a4377c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351398Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69413}
      22874998
  18. 12 Aug, 2020 2 commits
  19. 06 Aug, 2020 1 commit
  20. 29 May, 2020 1 commit
  21. 27 May, 2020 2 commits
  22. 26 May, 2020 1 commit
  23. 20 May, 2020 1 commit
  24. 19 May, 2020 3 commits
  25. 12 May, 2020 1 commit
  26. 02 Mar, 2020 1 commit
  27. 21 Feb, 2020 1 commit
  28. 18 Dec, 2019 1 commit
    • Nico Hartmann's avatar
      [torque] Enum language feature · fdc9fade
      Nico Hartmann authored
      This CL implements enums in Torque in three steps:
      
      1.) It implements necessary changes to Torque's type system. In
      particular, the constraints on constexpr types are relaxed such that
      constexpr types can exist without a corresponding non-constexpr
      version. Furthermore, constexpr and their non-constexpr counterpart
      need not be of the same kind of type. This allows an AbstractType to
      have a UnionType as its non-constexpr counterpart.
      
      2.) The enum feature itself is realized as a pure desugaring in the
      parser, where all required types, constants and macro specializations
      (like FromConstexpr<>) are generated from a simple enum declaration,
      such that enum entries are not just constants, but are namespace
      scoped and have distinct types so that they can be used within
      typeswitch constructs.
      
      3.) Almost all of the existing constants defined in torque
      (.tq files) are ported to new enum definitions.
      
      Bug: v8:10053
      Change-Id: I72426d3b1434f301fd690847e15603de0dc1021b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964392
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65503}
      fdc9fade
  29. 20 Nov, 2019 1 commit
  30. 16 Nov, 2019 1 commit
  31. 13 Nov, 2019 1 commit
  32. 05 Nov, 2019 1 commit