1. 30 Jun, 2020 1 commit
    • Daniel Clifford's avatar
      [torque] Unused implicit parameters can be undefined · 9bd8e5f2
      Daniel Clifford authored
      e.g. the following is now valid Torque code:
      
        macro TestA(implicit c: Context)() {}
      
        macro TestB(): bool {
          return TestA();
        }
      
      This is handy for more flexible usage of generics that may or may not
      use implicit parameters deep inside their specializations.
      
      Note that this change doesn't change the fundamental rigor (or lack
      thereof) around checking the usage of implicit parameters, which
      already do not require '_' before their parameter identifier if
      unused. It just silences errors in cases where a call site doesn't
      implicitly pass a parameter that ultimately doesn't have a use site
      and adds meaningful error messages in the case that it does.
      
      Bug: v8:7793
      Change-Id: I559d06c0864a7e79fe52bee5a9a7af9941889748
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274127
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68618}
      9bd8e5f2
  2. 23 Jun, 2020 1 commit
    • Daniel Clifford's avatar
      [torque] generate Cast<> macros from Torque-defined classes · 1052dfb3
      Daniel Clifford authored
      This change enables automatic generation of Cast<> operators for
      classes that are defined in Torque.
      
      * Cast<> macros are generated for all classes that are defined in
        Torque code that are neither shapes nor marked with a new
        @doNotGenerateCast annotation.
      
      * Implicitly generated Cast macros simply call through to an
        internally-defined "DownCastForTorqueClass" macro that implements
        the cast using one of three strategies for efficiency. If the class
        has subclasses (i.e. a range of instance types including subtypes),
        the DownCastForTorqueClass checks for inclusion in the instance type
        range. If the class has a single instance type (i.e. no subclasses),
        then either 1) a map check is used if the class has a globally-
        defined map constant or 2) an equality check for the instance type
        is used.
      
      * Added new intrinsics to introspect class information, e.g. fetching
        instance type ranges for a class, accessing the globally-defined map
        for a class.
      
      * Removed a whole pile of existing explicit Cast<> operators that are
        no longer needed because of the implicitly generated Cast<> macros.
      
      * Added tests for the new Cast<> implementations.
      
      Bug: v8:7793
      Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68478}
      1052dfb3
  3. 26 May, 2020 1 commit
  4. 13 May, 2020 1 commit
  5. 05 May, 2020 1 commit
  6. 04 May, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] improve GC visitors · f1400e43
      Tobias Tebbi authored
      Summary of changes:
      
      - GC visitors no longer rely on superclass visitors, but instead visit
        everything themselves. This enables generating better code.
      - Try to match simple body descriptors to reduce the amount of generated
        code.
      - Turn SizeFor(instance) into an AllocatedSize() method.
      - Remove the special handling of resizable object sizes from Torque
        and instead overwrite AllocatedSize in classes that need special
        handling in C++.
      - Split the visitor id lists depending on whether the class has pointer
        fields.
      - Turn Torque-generated body descriptors into an .inc file to
        simplify includes.
      - Fix generated size functions to properly align the size.
      - Generate GC visitors (and C++ class definitions) for all string
        classes and FixedArray, WeakFixedArray, and WeakArrayList.
      - Store generated instance types in Torque class types. This is only
        used to determine if a type has a single instance type in this CL.
      
      Bug: v8:7793
      Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67542}
      f1400e43
  7. 28 Apr, 2020 1 commit
  8. 22 Apr, 2020 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Allow storing to bitfield structs that are stored in Smis" · a9270e2b
      Seth Brenith authored
      This is a reland of 80843eda
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      Bug: v8:7793
      Change-Id: I783b6ec080042fec0e922927f6675dede458a072
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67305}
      a9270e2b
  9. 21 Apr, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] Allow storing to bitfield structs that are stored in Smis" · db61168a
      Francis McCabe authored
      This reverts commit 80843eda.
      
      Reason for revert: Causes compilation failure on macs
      
      https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
      
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
      
      Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67291}
      db61168a
    • Seth Brenith's avatar
      [torque] Allow storing to bitfield structs that are stored in Smis · 80843eda
      Seth Brenith authored
      This change:
      1. Updates the Torque compiler to allow direct access to bitfields that
         are packed within Smi values, which previously would have required a
         separate untagging step,
      2. Updates JSRegExpStringIterator to represent its flags in Torque,
      3. Adds reduction cases in MachineOperatorReducer for when the input to
         a branch or the left-hand side of a Word32Equals is based on a 64-bit
         shift-and-mask operation which has been truncated to 32 bits, as is
         the case in the code generated by step 1, and
      4. Adds a reduction case in MachineOperatorReducer to remove an extra
         Word64And operation added by step 1.
      
      Bug: v8:7793
      Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67290}
      80843eda
  10. 20 Apr, 2020 1 commit
  11. 08 Apr, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] remove HasIndexedField and cleanup internal class lists · 25808bbc
      Tobias Tebbi authored
      The two refactorings are somewhat orthogonal, but intersect at the
      class and instance type list generation, which is why it's easier to
      put them in one CL.
      
      For the removal of HasIndexedField, the removal is motivated by the
      fact that is no longer necessary, and that using a flag to store this
      kind of information is hacky.
      
      For the class list changes, this is a cleanup in that we no longer
      generate third-order macros, but instead normal macro lists.
      There is a functional change and bug-fix in that we no longer include
      abstract classes in lists that refer to instance types or maps. It's
      still somewhat broken though, so I can't test abstract internal classes
      yet, though. Coming in a follow-up CL.
      
      TBR=ulan@chromium.org
      
      Bug: v8:7793
      Change-Id: Ided8591370570ca3810d7991f53177ca32e03048
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108034
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67056}
      25808bbc
  12. 18 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] add const references and disallow const class field writes · d7e02ea4
      Tobias Tebbi authored
      - Allow type expression for abstract type supertypes.
        For consistency, and ease of implementation, also allow this for enums.
      - Allow subtyping of structs. This requires changing all places where we
        checked for struct types and instead check if we have a subtype of a
        struct type.
      - This allows defining two subtypes of the Reference<T> struct for
        mutable and constant references. Mutable references are a subtype of
        constant references.
      - &T desugars to MutableReference<T>
        const &T desugars to ConstReference<T>
      - A const field of a class produces a constant reference.
        A const field of a mutable reference to a struct is const.
        A mutable field of a const reference to a struct is const.
      - It is possible to assign a new struct value to a mutable reference to
        a struct, even if the struct contains const fields. This is analogous
        to allowing assignments of let-bound structs with constant fields.
      
      Not in this CL:
      - A notion of const slices.
      - Applying const to appropriate class fields.
      
      Bug: v8:7793
      Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66759}
      d7e02ea4
  13. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  14. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored
      This allows CoverageInfo to be distinguished from other kinds of
      FixedArray at runtime. I also updated it to use untagged data since it
      only stores ints, since that seems like the generally right thing to do
      (even though I doubt anybody allocates enough of these to notice the
      reduced GC work).
      
      Related Torque changes:
      - Allow structs containing untagged data to be used as class fields.
        This requires classifying them into the tagged or untagged sections of
        the class layout, and checking that their alignment requirements are
        met when stored in a packed array.
      - Generate a struct containing struct field offsets, so we can ensure
        that the layouts defined in Torque and C++ code match. Of course it
        would be nice to generate a lot more (indexed accessors, synchronized
        accessors, GC visitors, etc.), but we can't do it all at once.
      
      Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  15. 27 Dec, 2019 1 commit
    • Daniel Clifford's avatar
      Port bitfield ScopeFlags to Torque · 7e8a197c
      Daniel Clifford authored
      In the process:
      
      * Rework the Torque definition of ScopeInfo to enable direct
        field-style access of ScopeFlags, removing some dead code in
        the process.
      * Allow implicit FromConstexpr conversion from subtypes of
        'constexpr A' to other types. This makes it possible/easy to
        convert constexpr versions of enums to other types, since the
        constexpr version of the enum isn't addressable. It's namespace
        isn't a valid namespace and is an implementation detail anyway.
      * Cleanup LanguageMode: Language mode is now an enum and directly
        mirrors the C++-side definition rather than being a Smi. With
        the changes above, a new type LanguageModeSmi is introduced
        that is the Smi representation of LanguageMode that can be
        implicitly casted from constexpr LanguageMode values.
      
      Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65561}
      7e8a197c
  16. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] multiple arrays in one object · 59e8d45a
      Tobias Tebbi authored
      This allows the definition of classes with several arrays and ports
      SmallOrderedHashTable subclasses to Torque as an example, including
      the existing CSA allocation functions for them.
      
      Overview of changes:
      - Introduce ResidueClass to encapsulate the modulo-arithmetic
        necessary to do alignment checks.
      - Add MachineOperatorReducer to the CSA pipeline to address now
        missing CSA ad-hoc constant folding that got blocked by a
        temporary phi.
      - Allow assignments to references to structs. This is needed to
        initialize the data_table part of SmallOrderedHashMap.
      - Make the NumberLiteralExpression AST-node store a double instead
        of a string. This is necessary to detect arrays with constant size
        used for padding.
      - Turn offsets into base::Optional<size_t> to ensure we don't use
        an invalid or statically unknown offset.
      - Remove CreateFieldReferenceInstruction since it doesn't work for
        complex offset computations and the logic can be expressed better
        in ImplementationVisitor.
      - Validate alignment of structs embedded in classes.
      
      Bug: v8:10004 v8:7793
      Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65538}
      59e8d45a
  17. 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
  18. 17 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Load and store bitfields · d5f180b7
      Seth Brenith authored
      This change implements support for reading and writing bitfields from
      Torque code, and adds a couple of unit tests for this functionality. As
      Tobias suggested, the LocationReference for a bitfield access contains
      a nested LocationReference to where the bitfield struct is stored, so
      that store operations can read the original value, update part of it,
      and write it back.
      
      Bug: v8:7793
      Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65487}
      d5f180b7
  19. 12 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow expressions for array lengths · 6b663123
      Tobias Tebbi authored
      This allows arbitrary expressions to specify the length of an array.
      These expressions get access to globally declared things and the
      preceding fields of the current object.
      Unfortunately, this breaks generated C++ runtime code, so as a
      workaround, I special-case expressions that are just an identifier
      and handle them as before. We might want to support more cases there
      in the future, probably also with special-casing since having a full
      C++ back-end for Torque is infeasible.
      
      Bug: v8:10004 v8:7793
      
      Change-Id: I0d5d1200c0e727766beed7bfb2d43a8abb9cacf0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1942610
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65427}
      6b663123
  20. 10 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow allocation of strings · 8ed9be48
      Tobias Tebbi authored
      This CL generalizes and improves how we handle allocations in Torque.
      
      Overview of the changes:
      - Remove obsolete special handling for JSObject classes, since it was
        incomplete: It breaks as soon as slack tracking is active.
      - Handle array initialization using slices.
      - Properly align allocation sizes. This enabled allocating strings.
      - Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
        now than the old CSA code since allocation size alignment and
        large-object space allocation just happen out-of-the-box.
      - Remove obsolete or unnecessary intrinsics, some of them turn into
        macros in the torque_internal namespace.
      - Distinguish between header size and overall size for ClassType,
        make size optional and only defined when it is statically known.
      
      
      Bug: v8:10004 v8:7793
      Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65397}
      8ed9be48
  21. 06 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Add bitfield declarations · 57074692
      Seth Brenith authored
      This change is the first part of adding Torque support for a "bitfield
      struct", which represents a set of bitfields packed together into an
      integer value. With this change, Torque can generate the list of
      BitField template specializations that allow runtime code to use the
      bitfield values. The flags used in SharedFunctionInfo are converted to
      Torque to exercise this functionality. Bitfield values are not yet
      accessible directly from Torque code.
      
      Bug: v8:7793
      Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65371}
      57074692
  22. 21 Nov, 2019 2 commits
    • Tobias Tebbi's avatar
      [torque] shape: define in-object properties properly · cfab6505
      Tobias Tebbi authored
      This introduces a new keyword "shape" in addition to "class",
      which allows the definition of a type that extends a JSObject
      subclass and specifies one or several maps with statically
      known in-object properties.
      Differences compared to normal classes:
      - Shapes are transient since they specify maps instead of
        instance types.
      - Shapes have a known size.
      - Fields of shapes are always in-object properties. In particular,
        this means that their offset is after kHeaderSize.
      - It's forbidden to inherited from shapes.
      - Since shapes usually specify NativeContext-dependent maps, it's
        not possible to write runtime type-checks for them. Thus this CL
        avoids mapping them to their own TNode type, as the CAST macro
        won't work properly. We had runtime-checks for some of them
        nevertheless, some of them scarily confusing like
        IsJSSloppyArgumentsObject, that actually just checked the instance
        type.
      
      Drive-by cleanups and simplifications:
      - Allow subclassing from non-abstract classes and remove
        @dirtyInstantiatedAbstractClass. This attribute stems from a mis-
        conception of how instance types work, and with this change it
        ceases to have semantic influence.
      - Replace the existing JSArgumentsObject subclasses into two shapes.
        JSArgumentsObjectWithLength had to be removed since shapes don't
        support subclassing.
      - Place kHeaderSize correctly for objects with indexed fields.
      
      Design doc:
      https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU
      
      Bug: v8:8944
      
      Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65108}
      cfab6505
    • Tobias Tebbi's avatar
      [torque] add %SizeOf intrinsic · dddc6a90
      Tobias Tebbi authored
      This replaces the fragile hand-coded SizeOf function.
      
      Bug: v8:7793
      Change-Id: I6bd84f367182b947486192f8968c56723f29efaa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924265Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65089}
      dddc6a90
  23. 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
  24. 15 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Generate more detailed errors when instantiating generics · 332290e4
      Seth Brenith authored
      Currently it's pretty easy to write Torque code that generates an error
      in some common generic function such as Convert<To: type, From: type>,
      and unless your change is very small, it can be hard to figure out what
      part of it caused that macro specialization. This CL updates the Torque
      compiler to emit some extra information about the stack of code
      positions that caused a specialization of a macro or builtin, similar to
      what Clang does for C++ templates. Obviously there might be multiple
      places that require a particular specialization, but we only report the
      first one that caused the specialization to be created.
      
      Bug: v8:7793
      Change-Id: I4c0fbf1fd437d0eb0d7d5002baef7a5361aea5ee
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1911019
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64987}
      332290e4
  25. 14 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Strict verification of weak fields · 72d440d9
      Seth Brenith authored
      Now that we can represent specific weak types with Weak<T>, this CL
      updates the generated verifier functions so that they permit weak
      references only to the specified type. As an example, consider the
      verifier emitted for the following field in PrototypeInfo:
      
        object_create_map: Weak<Map>|Undefined;
      
      We used to emit the following, which allowed any weak reference:
      
        CHECK(object_create_map__value.IsWeakOrCleared()
            || object_create_map__value.GetHeapObjectOrSmi().IsOddball());
      
      With this change, we emit a stricter check:
      
        CHECK(object_create_map__value.IsCleared()
            || (!object_create_map__value.IsWeak()
                && object_create_map__value.GetHeapObjectOrSmi().IsOddball())
            || (object_create_map__value.IsWeak()
                && object_create_map__value.GetHeapObjectOrSmi().IsMap()));
      
      Bug: v8:7793
      Change-Id: I4be236d97dedbcdd6c98207928aee8bda2a77f00
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914613
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64965}
      72d440d9
  26. 11 Nov, 2019 1 commit
  27. 24 Oct, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] introduce generic abstract types · 5bba6680
      Tobias Tebbi authored
      This expands the existing mechanism for generic structs to also cover
      abstract types. This involves:
      - Moving the SpecializationKey from StructType to Type, so that it's
        also available to AbstractType.
      - Moving the generic parameters out of the StructDeclaration AST node
        and using the existing GenericDeclaration AST node for generic structs
        and abstract types too.
      - The GenericStructType declarable gets generalized to GenericType.
      
      This will be useful for defining a Weak<T> type for weak pointers.
      
      Bug: v8:7793
      Change-Id: I183b3a038a143cf0ae5888150104c4a025fd736c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859623
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64533}
      5bba6680
  28. 22 Oct, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] replace name mangling with unique numbering · 419b4e7e
      Tobias Tebbi authored
      Name mangling is hard to get right and not easy to read.
      This CL replaces the remaining name mangling of types and generics
      with simpler names that are not always unique, but then fixes them
      up by appending a unique counter.
      
      For struct types, this required an @export annotation since we use some
      struct types in CSA.
      
      Drive-by-fixes:
      
      - Overwrite the copy constructor of Type to clear the list
      of alias names when creating a new type.
      
      - Change the existing append-a-number scheme to have different
        counters for each name. This the number of changed names when adding
        something and is more readable.
      
      Bug: v8:7793
      Change-Id: Ied11ea1a251130f4562ddc0d81967368349e0bf6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866650
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64449}
      419b4e7e
  29. 14 Oct, 2019 1 commit
  30. 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
  31. 12 Sep, 2019 1 commit
  32. 21 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add user-defined Slice struct · 26e39d12
      Georg Schmid authored
      This CL consists of several preparatory steps for slices in Torque. Above all, it introduces a user-defined struct, torque_internal::Slice<T>, that performs bounds checking and returns references to elements in arrays. To enable this, several smaller changes were also made:
      
      - Constructors of internal classes such as torque_internal::Reference<T> now require a special 'Unsafe' argument, making it clear that there be dragons.
      - Struct methods are now declared during finalization. This allows instances of generic structs to have methods referring to the same struct. Previously, methods would be declared before the instance had been fully registered, leading to errors during type resolution. Furthermore, such methods were declared in a temporary namespace, that would then erroneously escape and lead to use-after-free issues.
      - Instances of TypeArgumentInference were not running in the correct (Torque) scopes, leading to type resolution errors.
      - The chain of ContextualVariable::Scope for any given ContextualVariable (such as CurrentScope) can now be walked, simplifying debugging.
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Bug: v8:7793
      Change-Id: I36f808f63cc3ce441062dfc56f511f24f1e3121e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758322
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63314}
      26e39d12
  33. 06 Aug, 2019 1 commit
  34. 02 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Infer type arguments of generic struct initializers · b1db8d84
      Georg Schmid authored
      Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
      
        struct Box<T: type> {
          const value: T;
        }
      
      one would initialize a new box using
      
        const aSmi: Smi = ...;
        const box = Box<Smi> { value: aSmi };
      
      With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
      
      Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63036}
      b1db8d84
  35. 31 Jul, 2019 1 commit
  36. 26 Jul, 2019 1 commit
  37. 23 Jul, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add Generic Structs · 1d9a5d88
      Georg Schmid authored
      This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType.
      
      As an example, consider a Tuple of types T1, T2:
      
        struct Tuple<T1: type, T2: type> {
          const fst: T1;
          const snd: T2;
        }
      
      which can be manipulated using generic macros, such as
      
        macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> {
          return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst};
        }
      
      Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly:
      
        const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2};
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Change-Id: I43111561cbe53144db473dc844a478045644ef6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62878}
      1d9a5d88
  38. 21 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Support 'real' internal classes · 76c1e829
      Sigurd Schneider authored
      Rework the implementation of non-external Torque classes to use
      Struct machinery rather than FixedArray machinery. This allows
      Torque-only defined 'internal' classes to the automatically generate
      class verifiers and printers.
      
      As part of this change, generate C++ boilerplate accessors for
      internal Torque classes, since this is a pre-requisite for the
      verifiers, printers and other Struct-based functionality.
      
      Moreover, augment the header-generating functionality in Torque
      to create separate header files for field offset definitions,
      internal class C++ definitions and instance types.
      
      Bug: v8:7793
      Change-Id: I47d5f1570040c2b44d378f23b6cf95d3d132dacc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607645
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62317}
      76c1e829