1. 14 May, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Introduce @abstract annotation for Torque classes · 4d05884e
      Sigurd Schneider authored
      This annotation indicates that the class itself is not instantiated,
      and does not have its own instance type: The instance types that
      logically belong to the class are the instance types of the derived
      classes.
      
      Currently, we need the indication @dirtyInstantiatedAbstractClass
      for several classes that are used as both, abstract base classes
      and concrete classes. The prime example is JSObject which is the
      base for many other classes, and also serves as the class to allocate
      plain JSObjects. The annotation is purposefully ugly because in the
      future we should refactor code to make it unnecessary.
      
      Another annotation we introduce is @hasSameInstanceTypeAsParent,
      which indicates another design pattern that currently occurs in the
      code-base: Some Torque classes have the same instance types as their
      parent class, but rename some fields, or possibly have a different map.
      In such cases, the parent class is not abstract and the derived classes
      can be seen as refinements of this class (that, for example, narrows the
      type of a field). In the future, Torque should accomodate this pattern
      better, but at moment we are content with just indicating where it is
      used.
      
      Bug: v8:7793
      Change-Id: I1892dcc7325250df75d80308bf3d767d6d43bcc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607761
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61495}
      4d05884e
  2. 10 May, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Automatically generate verifier functions · e483fb27
      Seth Brenith authored
      This change generates functions that verify the things that Torque knows
      about objects and their fields. We still must implement each verifier
      function in objects-debug.cc, but we can call into the generated code to
      verify that field types match their Torque definitions. If no additional
      verification is required, we can use the macro USE_TORQUE_VERIFIER as a
      shorthand for a verifier that calls the corresponding generated
      function.
      
      A new annotation @noVerifier can be applied to both class and field
      definitions, to prevent generating verification code. This allows fully
      customized verification for complicated cases like
      JSFunction::prototype_or_initial_map, which might not exist at all, and
      JSObject::elements, which might be a one pointer filler map.
      
      Because Factory::InitializeJSObjectFromMap fills new objects with
      undefined values, and many verifiers need to deal with partially-
      initialized objects, the generated verifiers allow undefined values on
      every class deriving from JSObject. In cases where stricter checks were
      previously performed, they are kept in objects-debug.cc.
      
      Bug: v8:7793
      Change-Id: I84034efadca89ba0aceddf92e886ffbfaa4c23fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594042
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61422}
      e483fb27
  3. 08 May, 2019 1 commit
  4. 07 May, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Make torque declarations order independent · 70678d53
      Sigurd Schneider authored
      Torque semantic analysis is now a four-stage process:
      
       1. The TypeDeclarationVisitor introduces a TypeAlias for every
          TypeDeclaration* (or derived) in the Torque source, but does
          not process the TypeDeclaration* itself.
       2. All aliases are resolved in a dependency respecting manner.
          This CL also changes struct member resolution to happen at
          this point already. Types for classes are created, but their
          members are not resolved to allow classes to mutually reference
          each other in their field types.
       3. 'value' declarations (macros, etc.) are processed.
       4. Members of classes are processed.
      
      Bug: v8:7793
      Change-Id: I46108555a5cdf30df03c5d4399ec786ee6cc6df4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584319
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61264}
      70678d53
  5. 11 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] add references to HeapObject fields. · a9a1a3bb
      Tobias Tebbi authored
      This adds references to HeapObject fields to Torque.
      The syntax is based on Rust (which is essentially C pointer syntax).
      
      The type &T is a reference to T (which must be a scalar type for now).
      We can create references from field access expressions, using the
      addressof(&) operator:
        &obj.fieldname
      To read or assign a reference, we use the dereference(*) operator:
        *someref = *otherref
      
      This CL also uses references internally normal class field accesses,
      but only if there is no overload for field accessor functions.
      This allows to have overloaded field accessors for a subtype like
      FastJSArray. However, there is a change in behavior in that an
      operator ".fieldname" will stop reference creation and will therefore
      also stop write access to a class field of the same name. That's why
      this CL had to add a write overload ".length=" for FastJSArray.
      
      References desugar to a pair of a tagged HeapObject pointer and an
      untagged offset into this HeapObject. On the CSA-side, they are
      represented by the C++ struct
      
      struct TorqueReference {
        TNode<HeapObject> object;
        TNode<IntPtrT> offset;
      };
      
      Bug: v8:7793
      Change-Id: Ica6468d47847bd68fb6b85f731cf8fbe142fa401
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557151
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60780}
      a9a1a3bb
  6. 04 Apr, 2019 2 commits
    • Daniel Clifford's avatar
      [torque] Indexed class field initialization · 62a32805
      Daniel Clifford authored
      Indexed fields in classes can now be initialized using iterators
      and a spread syntax, e.g.:
      
        class Foo {
          length: Smi;
          elements[length]: Object;
        }
      
        new Foo{length: 5, elements: ...iter};
      
      where iter implements Torque's iterator protocol. This protocol
      requires the definition of a method with the following signature:
      
        Next(): <type> labels NoMore;
      
      Where <type> is the Torque type of the values to be iterated.
      In the case of indexed field initialization, the type must be
      the field's type or a subtype thereof.
      
      Field initialization with spread is desugared into a loop that
      calls the spread iterator's Next method and assigns each
      returned value in order to the corresponding indexed field
      element.
      
      The general machinery for the spread syntax has been added to
      the ast and parser, however, it can currently only be used in
      the specific context of indexed field initialization. Spread
      operators used in any other context will cause an error.
      
      Bug: v8:7793
      Change-Id: If071e61db8166573c28d13318879c88ba96f6d98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550407
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60639}
      62a32805
    • Tobias Tebbi's avatar
      [torque] named arguments for constructors · e87e3b1f
      Tobias Tebbi authored
      This changes the syntax for constructing structs and classes to explicitly
      mention the fieldnames, similar to JavaScript object literals.
      The fields still have to be listed in the same order as in the struct/class
      declaration.
      As in Javascript, {foo: foo} can be abbreviated as {foo}.
      
      Example:
      
      macro NewJSArray(implicit context: Context)(
          map: Map, elements: FixedArrayBase): JSArray {
        return new JSArray{
          map,
          properties_or_hash: kEmptyFixedArray,
          elements,
          length: elements.length
        };
      }
      
      Drive-by cleanup: Make struct and class constructors follow the same pattern
                        in the parser and the AST.
      
      Bug: v8:9018 v8:7793
      Change-Id: I22ff7f68270e4f406aa80731a709d41ea52f52bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1551999Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60622}
      e87e3b1f
  7. 03 Apr, 2019 1 commit
  8. 27 Feb, 2019 2 commits
  9. 15 Feb, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] make overload resolution robust concerning branching contexts · 93c13714
      Tobias Tebbi authored
      This changes the behavior of overload resolution to not consider if the
      call happens in a branching context (i.e., with implicit True and False
      labels from a conditional operator or statement).
      That way, it is not possible to get different behavior accidentially
      by using an operator in the wrong context. Instead, there will be a
      compile error because the call happened in a non-branching context, or
      because it is ambiguous without this information.
      
      The test doesn't perfectly fit the issue (impossible until we have
      negative tests), but instead tests that equality on HeapNumber's works
      in boolean contexts, which is something Peter fixed already in
      https://crrev.com/c/1432596.
      
      
      Bug: v8:8737 v8:7793
      Change-Id: I08a3801891587aac705dc93b1c65b0c6cf164107
      Reviewed-on: https://chromium-review.googlesource.com/c/1456093Reviewed-by: 's avatarPeter Wong <peter.wm.wong@gmail.com>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59625}
      93c13714
  10. 07 Feb, 2019 1 commit
  11. 06 Feb, 2019 2 commits
  12. 05 Feb, 2019 1 commit
  13. 04 Feb, 2019 1 commit
  14. 22 Jan, 2019 3 commits
    • Daniel Clifford's avatar
      Reland "[torque] Implement safe initialization of classes through hidden structs" · 4c9bc648
      Daniel Clifford authored
      This is a reland of d11a0648
      
      Original change's description:
      > [torque] Implement safe initialization of classes through hidden structs
      > 
      > Initialization of classes now happens atomically at the end of the
      > class constructor only once all of the values for the class' fields
      > have been fully computed. This makes Torque constructors completely
      > GC safe, e.g. hardened against allocations or exceptions in
      > constructors.
      > 
      > As part of this change, make the 'this' parameter for method calls
      > explicit rather than implicit.
      > 
      > Drive by: add validation to check for duplicate field declarations
      > 
      > Bug: v8:7793
      > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      > Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      > Commit-Queue: Daniel Clifford <danno@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58979}
      
      Bug: v8:7793
      Change-Id: Ia8c23a36a661a73b5dc34437efd514a7c13a1ae8
      Reviewed-on: https://chromium-review.googlesource.com/c/1426840Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59005}
      4c9bc648
    • Daniel Clifford's avatar
      Revert "[torque] Implement safe initialization of classes through hidden structs" · 8c17e114
      Daniel Clifford authored
      This reverts commit d11a0648.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [torque] Implement safe initialization of classes through hidden structs
      > 
      > Initialization of classes now happens atomically at the end of the
      > class constructor only once all of the values for the class' fields
      > have been fully computed. This makes Torque constructors completely
      > GC safe, e.g. hardened against allocations or exceptions in
      > constructors.
      > 
      > As part of this change, make the 'this' parameter for method calls
      > explicit rather than implicit.
      > 
      > Drive by: add validation to check for duplicate field declarations
      > 
      > Bug: v8:7793
      > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      > Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      > Commit-Queue: Daniel Clifford <danno@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58979}
      
      TBR=danno@chromium.org,tebbi@chromium.org
      
      Change-Id: Id6c46c175f53c5a77db1e6ca242586fba34cd02e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/1426121Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58980}
      8c17e114
    • Daniel Clifford's avatar
      [torque] Implement safe initialization of classes through hidden structs · d11a0648
      Daniel Clifford authored
      Initialization of classes now happens atomically at the end of the
      class constructor only once all of the values for the class' fields
      have been fully computed. This makes Torque constructors completely
      GC safe, e.g. hardened against allocations or exceptions in
      constructors.
      
      As part of this change, make the 'this' parameter for method calls
      explicit rather than implicit.
      
      Drive by: add validation to check for duplicate field declarations
      
      Bug: v8:7793
      Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58979}
      d11a0648
  15. 17 Jan, 2019 2 commits
  16. 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
  17. 17 Dec, 2018 1 commit
  18. 14 Dec, 2018 1 commit
    • Daniel Clifford's avatar
      [builtins] Port GetArgumentsFrameAndCount to Torque · a74afec6
      Daniel Clifford authored
      In the process, add the bint type (which stands for Best-INTeger),
      which implements Torque's idea of CSA's ParameterMode. It maps to
      a different type on 32-bit (Smi) and 64-bit (intptr). There are
      convert operators that are either no-ops or conversions
      to-and-from Smi and intptrs on the each platform, depending on
      the underlying type for bint. This allows Torque code to git most
      of the benefits of ParameterMode without having to explicitly
      pass around the mode, since it is almost always OptimalMode anyways.
      
      Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162
      Reviewed-on: https://chromium-review.googlesource.com/c/1361160
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58253}
      a74afec6
  19. 07 Dec, 2018 1 commit
  20. 27 Nov, 2018 1 commit
  21. 19 Nov, 2018 1 commit
  22. 14 Nov, 2018 1 commit
  23. 13 Nov, 2018 1 commit
  24. 09 Nov, 2018 1 commit
  25. 05 Nov, 2018 2 commits
    • Tobias Tebbi's avatar
      [torque] allow qualified access to different modules/namespaces · ece9156c
      Tobias Tebbi authored
      This introduces a new syntax for identifiers and calls: modulename::foo.
      Such a name is resolved by trying to find a module modulename in one of
      the parent scopes and looking for foo there. So this roughly corresponds
      to C++ qualified namespace lookup.
      
      Bug: v8:7793
      Change-Id: Iedc43e6ebe125cd74575cbbcbf990bbcc0155a1f
      Reviewed-on: https://chromium-review.googlesource.com/c/1309818
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57238}
      ece9156c
    • Tobias Tebbi's avatar
      [torque] cleanup generics and scopes · 06c8ce59
      Tobias Tebbi authored
      - Name lookup in module scopes has namespace semantics now: All
        overloads from all parent modules are combined before overload
        resolution.
      - Allow overloads of different callables: runtime-functions,
        macros, builtins, and generics.
      - The duplication between the DeclarationVisitor and the
        ImplementationVisitor is removed: The DeclarationVisitor creates
        declarables for everything except for implicit generic specializations.
        The ImplementationVisitor iterates over declarables.
        The DeclarationVisitor only looks at the header of declarations, not
        at the body.
      - Modules become Declarable's, which will enable them to be nested.
      - Modules replace the existing Scope chain mechanism, which will make it
        easier to inline macros.
      - The DeclarationVisitor and Declarations become stateless. All state is
        moved to contextual variables and the GlobalContext.
      - Implicit specializations are created directly from the
        ImplementationVisitor. This will enable template parameter inference.
      - As a consequence, the list of all builtins is only available after the
        ImplementationVisitor has run. Thus GenerateBuiltinDefinitions has to
        move to the ImplementationVisitor. Also, this makes it necessary to
        resolve the link from function pointer types to example builtins only
        at this point.
      
      
      Bug: v8:7793
      Change-Id: I61cef2fd3e954ab148c252974344a6e38ee2d01d
      Reviewed-on: https://chromium-review.googlesource.com/c/1304294
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57231}
      06c8ce59
  26. 31 Oct, 2018 4 commits
  27. 24 Oct, 2018 1 commit
  28. 08 Oct, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Allow atomarStatements in otherwise statements · 6f5600e2
      Daniel Clifford authored
      In the process:
      - Convert TryLabelStatements into TryLabelExpressions
      - Change TryLabelExpressions to support only single label blocks and de-sugar
        try/labels into nested try/label statements. This allows the code in a label
        block to goto subsequent labels in the same try/label statement.
      - Make otherwise expressions either take IdentifierExpressions which get
        converted into simple label names OR atomarStatements, which make useful
        non-label operations, like 'break' and 'continue', useful together with
        otherwise. Non-label otherwise statements get de-sugared into try/label
        blocks.
      
      Bug: v8:7793
      Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db
      Reviewed-on: https://chromium-review.googlesource.com/c/1266997
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56447}
      6f5600e2
  29. 04 Oct, 2018 1 commit
  30. 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