1. 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
  2. 26 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Support bitfield structs stored within Smis" · 527f9de1
      Seth Brenith authored
      This reverts commit 4dc1fb4e.
      
      Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
      
      Original change's description:
      > Revert "[torque] Support bitfield structs stored within Smis"
      >
      > This reverts commit e5e4ea96.
      >
      > Reason for revert: mysterious performance regression chromium:1052756
      >
      > Original change's description:
      > > [torque] Support bitfield structs stored within Smis
      > >
      > > This change moves the definition of the bits stored in DebugInfo::flags
      > > to Torque, and updates the only Torque usage of that field to use more
      > > natural syntax. This is intended as an example of common patterns found
      > > in various other classes. Several supporting changes are required:
      > >
      > > 1. Add a new type representing a bitfield struct stored within a Smi. It
      > >    is currently called SmiTagged, but I'm open to suggestions.
      > > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      > >    occupy only one bit each.
      > > 3. Add a new case to MachineOperatorReducer that makes the generated
      > >    code for IncBlockCounter match with what was generated before this
      > >    change.
      > > 4. Add support for reporting these bitfields in the postmortem debugging
      > >    API. The format matches existing bitfields but with an offset value
      > >    that includes the SMI shift size.
      > >
      > > Bug: v8:7793
      > > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66182}
      >
      > Bug: chromium:1052756, v8:7793
      > Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66349}
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66465}
      527f9de1
  3. 19 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque] Support bitfield structs stored within Smis" · 4dc1fb4e
      Seth Brenith authored
      This reverts commit e5e4ea96.
      
      Reason for revert: mysterious performance regression chromium:1052756
      
      Original change's description:
      > [torque] Support bitfield structs stored within Smis
      >
      > This change moves the definition of the bits stored in DebugInfo::flags
      > to Torque, and updates the only Torque usage of that field to use more
      > natural syntax. This is intended as an example of common patterns found
      > in various other classes. Several supporting changes are required:
      >
      > 1. Add a new type representing a bitfield struct stored within a Smi. It
      >    is currently called SmiTagged, but I'm open to suggestions.
      > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      >    occupy only one bit each.
      > 3. Add a new case to MachineOperatorReducer that makes the generated
      >    code for IncBlockCounter match with what was generated before this
      >    change.
      > 4. Add support for reporting these bitfields in the postmortem debugging
      >    API. The format matches existing bitfields but with an offset value
      >    that includes the SMI shift size.
      >
      > Bug: v8:7793
      > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66182}
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66349}
      4dc1fb4e
  4. 07 Feb, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Support bitfield structs stored within Smis · e5e4ea96
      Seth Brenith authored
      This change moves the definition of the bits stored in DebugInfo::flags
      to Torque, and updates the only Torque usage of that field to use more
      natural syntax. This is intended as an example of common patterns found
      in various other classes. Several supporting changes are required:
      
      1. Add a new type representing a bitfield struct stored within a Smi. It
         is currently called SmiTagged, but I'm open to suggestions.
      2. Add an enum-style output for Torque bitfield structs whose bitfields
         occupy only one bit each.
      3. Add a new case to MachineOperatorReducer that makes the generated
         code for IncBlockCounter match with what was generated before this
         change.
      4. Add support for reporting these bitfields in the postmortem debugging
         API. The format matches existing bitfields but with an offset value
         that includes the SMI shift size.
      
      Bug: v8:7793
      Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      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@{#66182}
      e5e4ea96
  5. 16 Jan, 2020 1 commit
  6. 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
  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. 16 Dec, 2019 1 commit
  9. 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
  10. 05 Dec, 2019 1 commit
  11. 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
  12. 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
  13. 11 Nov, 2019 1 commit
  14. 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
  15. 26 Jul, 2019 1 commit
  16. 09 Jul, 2019 1 commit
  17. 18 Jun, 2019 1 commit
  18. 11 Jun, 2019 3 commits
  19. 06 Jun, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Add lint errors for unused variable and label bindings · 0e53739c
      Simon Zünd authored
      This CL adds lint errors when 'let' bindings, arguments and labels
      are not used. Note that errors for 'const' bindings will be added
      later.
      
      In cases where arguments are actually needed to match the signature,
      the warning can be silenced by prefixing identifiers with "_". This
      might be needed for generic specializations or builtins called from
      TurboFan. Trying to use a variable or label that was marked with
      "_" results in a compilation error.
      
      Implicit arguments are not linted. They are implemented using exact
      string matching. Prefixing an implicit argument with "_" in a callee
      would break all callers as the names would no longer match.
      
      Drive-by: Fix all new lint errors in the existing Torque code.
      
      Bug: v8:7793
      Change-Id: I68b3c59c76b956e9f88709e9388a40a19546ce52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645092
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62027}
      0e53739c
  20. 05 Jun, 2019 1 commit
  21. 03 Jun, 2019 1 commit
  22. 24 May, 2019 2 commits
  23. 23 May, 2019 4 commits
  24. 21 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque] More flexibel and uniform error reporting · bdfd1e4b
      Simon Zünd authored
      This CL changes the existing TorqueError struct into a more general
      TorqueMessage by adding a "kind" enum. The contextual for lint errors
      is removed and replaced by a list of TorqueMessages.
      
      A MessageBuilder is introduced to help with the different
      combinations of present information and method of reporting. A lint
      error with custom SourcePosition can be reported like this:
      
      Lint("naming convention error").Position(<src_pos_var>);
      
      While a fatal error, with CurrentSourcePosition can be thrown
      like this:
      
      Error("something went horrible wrong").Throw();
      
      This approach is both backwards compatible and should prove flexible
      enough to add more information to messages or add other message kinds.
      
      Bug: v8:7793
      Change-Id: Ib04fa188e34b3e8e9a6526a086f80da8f690a6f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617245
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61696}
      bdfd1e4b
  25. 14 May, 2019 2 commits
  26. 08 May, 2019 1 commit
    • Simon Zünd's avatar
      Reland "[torque] Introduce force_assert_statements compiler option" · 2e3862d7
      Simon Zünd authored
      This is a reland of 2d45ecf0
      
      The reland properly initializes struct fields in unittests. To prevent
      this in the future, TorqueCompilerOptions uses brace initialization.
      
      Original change's description:
      > [torque] Introduce force_assert_statements compiler option
      >
      > "assert(...)" statements are usually only visited and generated in
      > debug builds. To provide Language Server support for statements inside
      > asserts, the force_assert_statements option allows to manually
      > override this behavior and visit assert statements in release builds.
      >
      > R=sigurds@chromium.org
      >
      > Bug: v8:7793
      > Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180
      > Auto-Submit: Simon Zünd <szuend@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61295}
      
      Bug: v8:7793
      Change-Id: I96ef863c8c85ae87a00cbe858655d4a2c9368b41
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599599
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61315}
      2e3862d7
  27. 07 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque-ls] Add boilerplate for DocumentSymbol requests and responses · 034defad
      Simon Zünd authored
      DocumentSymbol responses provide all symbols (macros, classes, etc.)
      in a given document. The LSP standard evolved over time and supports
      two different kind of responses here:
        - A simpler one, that is a plain list of all the symbols
        - A more detailed one, allowing a hierarchy of symbols. For example
          a class symbol has a list of field/method symbols attached. This
          is used by editors to build hierarchical outline views.
      
      For now, the simpler response is chosen as its also used for
      workspace wide symbol searches.
      
      This CL adds the necessary boilerplate so the actual implementation CL
      is easier to review.
      
      R=tebbi@chromium.org
      
      Bug: v8:8880
      Change-Id: I6c86fc839b1f4e0309f6403a5f9afd5c162c0e89
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598757
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61294}
      034defad
  28. 06 May, 2019 2 commits
  29. 02 May, 2019 2 commits
  30. 25 Apr, 2019 2 commits