1. 30 Sep, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Make return types required · 25f0e329
      Seth Brenith authored
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77178}
      25f0e329
  2. 14 Sep, 2021 1 commit
  3. 12 May, 2020 1 commit
  4. 06 May, 2020 1 commit
  5. 04 May, 2020 1 commit
  6. 29 Apr, 2020 1 commit
  7. 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
  8. 20 Nov, 2019 1 commit
  9. 06 Nov, 2019 1 commit
  10. 23 Oct, 2019 1 commit
  11. 26 Aug, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] introduce JSAny type for user-accessible JavaScript values" · 1ef99b93
      Tobias Tebbi authored
      Changes in the reland: Rebased and added a check that JavaScript-linkage
      builtins use JSAny in parameters and return type, plus the necessary
      cleanups for this test to pass.
      
      Design Doc: https://docs.google.com/document/d/1z6j0pWHnNIfId0v00uWN2HBrGRDJxJfYuCr5K7Kr1xA
      
      This reverts commit 4418a7b9.
      
      Original change's description:
      > Revert "[torque] introduce JSAny type for user-accessible JavaScript values"
      >
      > This reverts commit 79b00555.
      >
      > Reason for revert: needs more discussion
      >
      > Original change's description:
      > > [torque] introduce JSAny type for user-accessible JavaScript values
      > >
      > > This CL introduces a JSAny type for user-exposed JavaScript values and
      > > a few new types to define it. Especially, it splits Symbol into
      > > PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      > > symbols).
      > >
      > > The change is mostly mechanical, but a few things are interesting:
      > > - PropertyKey and JSPrimitive were designed to coincide with the spec
      > >   notions of IsPropertyKey() and primitive value, respectively.
      > > - Since Name is an open type, we define AnyName to be the known
      > >   subtypes of Name. This is not too elegant, but by using AnyName
      > >   instead of Name, typeswitch can properly conclude something if a
      > >   subtype of Name is excluded.
      > >
      > > Small drive-by changes, which were necessary:
      > > - Allow subtyping on label parameters.
      > > - Fix the formatting of typeswitch, it was broken with union types
      > >   in case types.
      > >
      > > Bug: v8:7793
      > > Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63114}
      >
      > TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      >
      > Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:7793
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63115}
      
      TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7793
      Change-Id: Icca34e3824f55009b984d9348fd21884400f0081
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769316
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63395}
      1ef99b93
  12. 07 Aug, 2019 2 commits
    • Tobias Tebbi's avatar
      Revert "[torque] introduce JSAny type for user-accessible JavaScript values" · 4418a7b9
      Tobias Tebbi authored
      This reverts commit 79b00555.
      
      Reason for revert: needs more discussion
      
      Original change's description:
      > [torque] introduce JSAny type for user-accessible JavaScript values
      > 
      > This CL introduces a JSAny type for user-exposed JavaScript values and
      > a few new types to define it. Especially, it splits Symbol into
      > PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      > symbols).
      > 
      > The change is mostly mechanical, but a few things are interesting:
      > - PropertyKey and JSPrimitive were designed to coincide with the spec
      >   notions of IsPropertyKey() and primitive value, respectively.
      > - Since Name is an open type, we define AnyName to be the known
      >   subtypes of Name. This is not too elegant, but by using AnyName
      >   instead of Name, typeswitch can properly conclude something if a
      >   subtype of Name is excluded.
      > 
      > Small drive-by changes, which were necessary:
      > - Allow subtyping on label parameters.
      > - Fix the formatting of typeswitch, it was broken with union types
      >   in case types.
      > 
      > Bug: v8:7793
      > Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63114}
      
      TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63115}
      4418a7b9
    • Tobias Tebbi's avatar
      [torque] introduce JSAny type for user-accessible JavaScript values · 79b00555
      Tobias Tebbi authored
      This CL introduces a JSAny type for user-exposed JavaScript values and
      a few new types to define it. Especially, it splits Symbol into
      PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      symbols).
      
      The change is mostly mechanical, but a few things are interesting:
      - PropertyKey and JSPrimitive were designed to coincide with the spec
        notions of IsPropertyKey() and primitive value, respectively.
      - Since Name is an open type, we define AnyName to be the known
        subtypes of Name. This is not too elegant, but by using AnyName
        instead of Name, typeswitch can properly conclude something if a
        subtype of Name is excluded.
      
      Small drive-by changes, which were necessary:
      - Allow subtyping on label parameters.
      - Fix the formatting of typeswitch, it was broken with union types
        in case types.
      
      Bug: v8:7793
      Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63114}
      79b00555
  13. 06 Aug, 2019 1 commit
  14. 14 Jun, 2019 3 commits
  15. 11 Jun, 2019 1 commit
  16. 07 Jun, 2019 1 commit
  17. 02 May, 2019 1 commit
  18. 11 Apr, 2019 1 commit
  19. 27 Feb, 2019 1 commit
  20. 05 Feb, 2019 1 commit
  21. 09 Dec, 2018 1 commit
  22. 05 Dec, 2018 1 commit
  23. 03 Dec, 2018 1 commit
  24. 13 Nov, 2018 1 commit
  25. 05 Nov, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] qualified access to CSA assemblers · 23b48920
      Tobias Tebbi authored
      No longer use inheritance to associate Torque-generated assemblers
      with corresponding CSA subclasses. Instead, all references to CSA
      and CSA-derived assemblers are now explicitly qualified, by generating
      a short-lived assembler instance in-place. As a consequence, Torque
      files have to mention the assembler external macros live in.
      The CodeStubAssembler is the default for this and can be omitted.
      As a drive-by cleanup, also distinguish between names that are emitted
      in C++ and names that are intended to be read in error messages. This
      is relevant for generic instantiations, where the generated names are
      rather unreadably mangled.
      
      As a follow-up, it will be easy to allow for qualified access to
      different modules, thus implementing full namespace semantics for
      modules.
      
      Bug: v8:7793
      Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950
      Reviewed-on: https://chromium-review.googlesource.com/c/1309636
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57235}
      23b48920
  26. 29 Oct, 2018 1 commit
  27. 24 Sep, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Improve formatting in format-torque · f088840a
      Daniel Clifford authored
      Issues/problems addressed:
      
      - Fix line-wrapping and indenting for long declarations including strings,
        e.g. generates and constexpr clauses.
      - Implement proper formatting for typeswitch statements
      - Fix formatting of operator declarations
      - Fix formatting of constexpr if-clauses (the constexpr is now included on the
        same line as the if and it doesn't mess up the formatting that
      - Fix formatting of label declarations on callables, the "label" keyword now
        always starts a new line with indentation.
      - Remove space after identifier name in generic parameter declarations, e.g.
        "<a : T>" is now "<a: T>" which is consistent with type specification
        formatting elsewhere.
      - Indent "otherwise" clauses that have been pushed to the next line.
      
      Also ran the formatter over all existing .tq files.
      
      Bug: v8:7793
      Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71
      Reviewed-on: https://chromium-review.googlesource.com/1238580
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56158}
      f088840a
  28. 20 Sep, 2018 1 commit
    • Michael Achenbach's avatar
      Revert "[es2015] Introduce JSDataView::external_pointer." · ec216398
      Michael Achenbach authored
      This reverts commit 46573e51.
      
      Reason for revert: Speculative revert for breaking chromium integration.
      
      Might break gpu tests and linux debug:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/Mac%20V8%20FYI%20Release%20(Intel)/2554
      
      Also blocks the roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1234328
      
      Original change's description:
      > [es2015] Introduce JSDataView::external_pointer.
      > 
      > This adds a new external_pointer field to every JSDataView instance
      > which points directly into the backing store at the given view's
      > byte_offset. This was the DataView performance is now almost on
      > par with the TypedArray performance for accessing aligned memory
      > (with appropriate endianess). This also serves as prepatory work
      > to enable full 64-bit addressing of DataView backing stores in
      > optimized code (soonish).
      > 
      > This change optimizes the bounds checking sequence in TurboFan in
      > such a way that it further improves the DataView set/get performance
      > by around 10%, almost closing the remaining gap between DataViews
      > and TypedArrays.
      > 
      > Drive-by-fix: Get rid of the code duplication around DataView inlining
      > in the JSCallReducer and have only a single bottleneck method now.
      > 
      > Bug: chromium:225811, v8:4153, v8:7881, v8:8171
      > Change-Id: I9118efd4d19e93f0e51c931a9bec1a56a0f4593e
      > Reviewed-on: https://chromium-review.googlesource.com/1231994
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56042}
      
      TBR=yangguo@chromium.org,mlippautz@chromium.org,tebbi@chromium.org,bmeurer@chromium.org
      
      Change-Id: I614a90043b1574b19936c37987db94806cac3bd7
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811, v8:4153, v8:7881, v8:8171
      Reviewed-on: https://chromium-review.googlesource.com/1234417Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56059}
      ec216398
  29. 19 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce JSDataView::external_pointer. · 46573e51
      Benedikt Meurer authored
      This adds a new external_pointer field to every JSDataView instance
      which points directly into the backing store at the given view's
      byte_offset. This was the DataView performance is now almost on
      par with the TypedArray performance for accessing aligned memory
      (with appropriate endianess). This also serves as prepatory work
      to enable full 64-bit addressing of DataView backing stores in
      optimized code (soonish).
      
      This change optimizes the bounds checking sequence in TurboFan in
      such a way that it further improves the DataView set/get performance
      by around 10%, almost closing the remaining gap between DataViews
      and TypedArrays.
      
      Drive-by-fix: Get rid of the code duplication around DataView inlining
      in the JSCallReducer and have only a single bottleneck method now.
      
      Bug: chromium:225811, v8:4153, v8:7881, v8:8171
      Change-Id: I9118efd4d19e93f0e51c931a9bec1a56a0f4593e
      Reviewed-on: https://chromium-review.googlesource.com/1231994
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56042}
      46573e51
  30. 18 Sep, 2018 1 commit
  31. 11 Sep, 2018 1 commit
  32. 03 Aug, 2018 1 commit
    • Théotime Grohens's avatar
      [dataview] Fix too tight TNode type in DataView getters · 3656b465
      Théotime Grohens authored
      This CL fixes a bug found by Clusterfuzz, in which the functions
      LoadDataViewByteOffset and -ByteLength incorrectly had a return
      type of TNode<Smi> instead of TNode<Number>.
      
      This caused a CAST() call to fail when the requested byte offset
      or byte length did not fit inside a Smi, i.e. when the underlying
      ArrayBuffer of the DataView had a length longer than 2^30 on
      32-bit platforms.
      
      The CL also includes a new test in mjsunit to test against this.
      
      Bug: chromium:869313
      Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70
      Reviewed-on: https://chromium-review.googlesource.com/1158582
      Commit-Queue: Théotime Grohens <theotime@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54900}
      3656b465
  33. 24 Jul, 2018 1 commit
  34. 23 Jul, 2018 1 commit
  35. 05 Jul, 2018 1 commit
  36. 26 Jun, 2018 1 commit
  37. 25 Jun, 2018 1 commit