1. 17 Mar, 2022 1 commit
  2. 04 Mar, 2022 1 commit
  3. 04 Feb, 2022 1 commit
    • Michael Achenbach's avatar
      [infra] Make various scripts compatible with Python3 · efd28c14
      Michael Achenbach authored
      This fixes all Python3 problems in scripts and tests running via
      v8_presubmit.py. It includes:
      - Test runner
      - Release tools
      - Perf runner
      - Torque formatter
      - V8's main presubmit
      
      On bots, v8_presubmit is run with vpython, hence we also add
      the required dependencies. After the Python3 migration, most
      of the transitional code in this CL can be removed again.
      
      Bug: chromium:1293709,chromium:1292016
      Change-Id: Ic25e5965948b212c047e9d5194d2a4b6db1fa91b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432213Reviewed-by: 's avatarLiviu Rau <liviurau@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78936}
      efd28c14
  4. 21 Jul, 2021 1 commit
  5. 16 Jul, 2020 1 commit
  6. 12 May, 2020 1 commit
  7. 06 May, 2020 1 commit
  8. 01 May, 2020 1 commit
  9. 24 Oct, 2019 1 commit
  10. 11 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit
      
      Changes from the design doc:
      - Changed to use 'class' declarations rather than 'type' declarations
        for things that need instance types but whose layout is not known to
        Torque. These declarations end with a semicolon rather than having a
        full set of methods and fields surrounded by {}. If the class's name
        should not be treated as a class name in generated output (because
        it's actually a template, or doesn't exist at all), we use the
        standard 'generates' clause to declare the most appropriate C++ class.
      - Removed @instanceTypeName.
      - @highestInstanceType became @highestInstanceTypeWithinParentClassRange
        to indicate a semantic change: it no longer denotes the highest
        instance type globally, but only within the range of values for its
        immediate parent class. This lets us use it for Oddball, which is
        expected to be the highest primitive type.
      - Added new abstract classes JSCustomElementsObject and JSSpecialObject
        to help with some range checks.
      - Added @lowestInstanceTypeWithinParentClassRange so we can move the new
        classes JSCustomElementsObject and JSSpecialObject to the beginning of
        the JSObject range. This seems like the least-brittle way to establish
        ranges that also include JSProxy (and these ranges are verified with
        static assertions in instance-type.h).
      - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
      - Renamed @instanceTypeFlags to @reserveBitsInInstanceType.
      
      This change introduces the new annotations and adds the ability for
      Torque to assign instance types that satisfy those annotations. Torque
      now emits two new macros:
      - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
        InstanceType enumeration
      - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
        parts of INSTANCE_TYPE_LIST
      
      The design document mentions a couple of other macro lists that could
      easily be replaced, but I'd like to defer those to a subsequent checkin
      because this one is already pretty large.
      
      Bug: v8:7793
      Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
  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. 25 Jun, 2019 1 commit
  14. 14 Jun, 2019 3 commits
  15. 20 May, 2019 1 commit
  16. 18 May, 2019 1 commit
  17. 17 May, 2019 1 commit
  18. 16 May, 2019 2 commits
  19. 21 Feb, 2019 1 commit
  20. 20 Feb, 2019 2 commits
  21. 19 Feb, 2019 1 commit
  22. 08 Feb, 2019 1 commit
  23. 25 Jan, 2019 1 commit
  24. 24 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Correctly support JSObject allocation with 'new' · 32a92cf5
      Daniel Clifford authored
      This requires honoring the instance size of the object stored in the
      map for JSObject. To do this, allocation is now split into two
      instrinsics, one that calculates the base size of the allocated object
      (%GetAllocationBaseSize) and one that actually allocates (%Allocate).
      
      In the process, remove objects.tq, which only existed to contain a
      macro to fetch the default JSObject map, which is functionality that
      is now in the JSObject class constructor.
      
      Bug: v8:7793
      Change-Id: I426a7943aac67eacad46d4ff39f5c821489a04bc
      Reviewed-on: https://chromium-review.googlesource.com/c/1426959
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59052}
      32a92cf5
  25. 16 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Implement methods and constructors for structs and classes · b615dfa5
      Daniel Clifford authored
      With the changes in this patch,	it is now possible to add methods to
      both Torque's class and struct types. As a special case, "constructor"
      methods are used to initialize the values of classes and structs when
      they are constructed.
      
      The functionality in this patch	includes:
      
      - The refactoring of class- and struct-handling code to share field
        and method declaration code between both.
      
      - Addition of the "%Allocate" intrinsic that allocates raw bytes to be
        allocated from the V8 GC's NewSpace heap as the basis for freshly
        created, initialized class objects.
      
      - An implementation of a CallMethodExpression AST node that enables
        calling methods and constructors, including special handling of
        passing through the "this" pointer for method calls on structs by
        reference. The syntax for struct construction using "{}" remains as
        before, but now calls the struct's matching constructor rather than
        implicitly initializing the struct fields with the initialization
        arguments. A new syntax for allocation classes is introduced: "new
        ClassName{constructor_param1, constructor_param1, ...}", which
        de-sugars to an %Allocate call followed by a call to the matching
        constructor.
      
      - class	constructors can use the "super" keyword to initialize	their
        super class.
      
      - If classes and struct do not have a constructor, Torque creates a
        default constructor for them based on their field declarations,
        where each field's initial value is assigned to a same-typed
        parameter to the the default constructor. The default constructor's
        parameters are in field-declaration order, and for derived classes,
        the default constructor automatically uses a "super" initialization
        call to initialize inherited fields.
      
      - Class field declarations now automatically create ".field" and
        ".field=" operators that create CSA-compatible object accessors.
      
      - Addition of a no-argument constructor for JSArrays that creates an
        empty, PACKED_SMI_ELEMENTS JSArray using the machinery added
        elsewhere in this patch.
      
      Bug: v8:7793
      Change-Id: I31ce5f4b444656ab999555d780aeeba605666bfa
      Reviewed-on: https://chromium-review.googlesource.com/c/1392192
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58860}
      b615dfa5
  26. 10 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque]: Class declarations · d0e95c7a
      Daniel Clifford authored
      Class declarations support structured heap data that is a subtype of
      HeapObject. Only fields of Object subtypes (both strong and weak)
      are currently supported (no scalar fields yet).
      
      With this CL, both the field list macro used with the C++
      DEFINE_FIELD_OFFSET_CONSTANTS macro (to make field offset constants) as
      well as the Torque "operator '.field'" macros are generated for the
      classes declared in Torque. This is a first step to removing the
      substantial amount of duplication and boilerplate code
      needed to declare heap object classes.
      
      As a proof of concept, and handful of class field definitions,
      including those for non trivial classes like JSFunction, have been
      moved to Torque.
      
      Bug: v8:7793
      Change-Id: I2fa0b53db65fa6f5fe078fb94e1db3418f908753
      Reviewed-on: https://chromium-review.googlesource.com/c/1373971
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58704}
      d0e95c7a
  27. 05 Dec, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Add new and refine existing Torque intrinsic support · 79605b45
      Daniel Clifford authored
      Intrinsic changes:
      
      - Rename %RawCast to %RawObjectCast and add error checking so that it
        only applies to subtypes of Objects.
      
      - Add %RawPointerCast, which is similar to %RawObjectCast but must be
        used for all subtypes of RawPtr.
      
      - Add %RawConstexprCast, which allows one constexpr to be be cast to
        another at compile time. It translate to an appropriate static_cast
        in the generated code
      
      - Add %FromConstexpr, which handles most of the standard cases of
        generating XXXConstant CSA nodes from constexpr constants. It uses
        either SmiConstant, NumberConstant, StringConstant, IntPtrConstant
        or Int32Constant, depending on the cast-to type generic <To> type.
      
      - Add support for intrinsics that return constexpr results.
      
      Cleanup:
      
      - Turn FromConstexpr into a generic with two generic types, a <To> and
        a <From> type. Most FromConstexpr can use the new %FromConstexpr
        intrinsic rather than provide an explicit implementation.
      
      Bug: v8:7793
      Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464
      Reviewed-on: https://chromium-review.googlesource.com/c/1357049
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58049}
      79605b45
  28. 22 Nov, 2018 1 commit
  29. 21 Nov, 2018 4 commits
  30. 20 Nov, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] enable multiple inheritance from Torque-generated assemblers · 00ffe4a6
      Tobias Tebbi authored
      This enables more seamless interop between Torque and CSA:
      
      Since CodeStubAssembler can now inherit from the Torque base namespace,
      macros defined in the base namespace can be used in CodeStubAssembler
      macros, even without qualification.
      At the same time, macros in the base namespace can refer to
      CodeStubAssembler macros. The only new limitation is that types defined
      in code-stub-assembler.h cannot be referenced in the signature of macros
      defined in the base namespace, since this would produce a cyclic header
      dependency. A work-around for this woud be to put such types (like int31
      in this CL) into a separate header included by both. I (mis-)used
      code-assembler.h for that.
      Another side-effec is that types and enums defined in CodeStubAssembler
      have to be accessed in a qualified way from Torque.
      
      Other assemblers can now inherit from their Torque equivalent, so
      porting macros into the corresponding Torque namespace doesn't require
      any change to the existing use-sites.
      
      To avoid C++ ambiguities, the Torque-generated assemblers must not define
      anything also defined in Code(Stub)Assembler. This includes the type
      aliases for TNode, PLabel, ...
      My workaround is to qualify everything in the generated C++.
      
      As a drive-by fix, I had to change the formatter to avoid a situation
      where it doesn't compute a fixed point: putting a keyword at the
      beginning of a line removes the '\s' in front of it, so I replaced that
      with '\b'.
      
      Bug: v8:7793
      Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
      Reviewed-on: https://chromium-review.googlesource.com/c/1341955Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57645}
      00ffe4a6
  31. 13 Nov, 2018 2 commits