1. 21 Feb, 2019 1 commit
  2. 20 Feb, 2019 2 commits
  3. 19 Feb, 2019 1 commit
  4. 08 Feb, 2019 1 commit
  5. 04 Feb, 2019 1 commit
  6. 31 Jan, 2019 1 commit
  7. 25 Jan, 2019 1 commit
  8. 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
  9. 21 Jan, 2019 1 commit
  10. 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
  11. 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
  12. 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
  13. 22 Nov, 2018 1 commit
  14. 21 Nov, 2018 4 commits
  15. 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
  16. 13 Nov, 2018 4 commits
  17. 31 Oct, 2018 3 commits
  18. 29 Oct, 2018 1 commit
  19. 24 Oct, 2018 2 commits
  20. 19 Oct, 2018 3 commits
  21. 11 Oct, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Implement implicit parameters · 9958694f
      Daniel Clifford authored
      The implicit parameter syntax adds a second parameter list
      before the explicit parameter list when declaring macros, builtins and
      runtime functions:
      
        extern macro MyMacro(implicit a: Smi)(b: Oddball);
      
      when calling the macro, only the formal parameters can be provided
      at the call site. The implicit parameters are implicitly looked-up
      by name in the scope of the call and prepended to the explicit parameter
      list. The values that are found by name for each implicit parameter must
      be castable the corresponding implicit parameter type:
      
        MyMacro(Null);  // Error, a is not defined
        ...
        const a: Smi = 0;
        MyMacro(Null);  // OK
        ...
        const a: Object = 0;
        MyMacro(Null);  // Error, a has wrong type
      
      For external macros, builtins and runtime functions, the formal
      parameter list expected on the C++ side is the concatenation of the
      implicit and explicit parameter lists.
      
      As a drive-by: fix the formatting of typeswitch statements in the
      the presence of deferred-marked blocks and funky white space.
      
      Bug: v8:7793
      Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4
      Reviewed-on: https://chromium-review.googlesource.com/c/1270996
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56555}
      9958694f
  22. 25 Sep, 2018 2 commits
  23. 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
  24. 13 Sep, 2018 1 commit
  25. 20 Aug, 2018 1 commit
  26. 04 Jun, 2018 1 commit
  27. 29 May, 2018 1 commit
    • Simon Zünd's avatar
      [vscode-torque] Add vscode extension with basic Torque support. · 7975b8ce
      Simon Zünd authored
      This CL creates the "tools/torque" directory. It moves the existing
      two scripts (making the parser and formatting Torque code) into that
      director.
      
      The extension lives in "tools/torque/vscode-torque" and currently only
      provides basic syntax highlighting support. The easiest way to
      install the extension is to simply create a symlink into your local
      vscode extension directory (see README.md).
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Change-Id: Ifc22b615341ed18f91c9b046090f569fcc083ab6
      Reviewed-on: https://chromium-review.googlesource.com/1076548
      Commit-Queue: Simon Zünd <szuend@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53421}
      7975b8ce