1. 27 May, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] no longer generate assemblers per namespace · 19d8bfa5
      Tobias Tebbi authored
      Instead of generating one CodeStubAssembler-like class per namespace,
      Torque-generated macros are now free-standing functions not included
      from CSA code, and explicitly exported macros become part of the new
      TorqueGeneratedExportedMacrosAssembler, which CodeStubAssembler
      inherits from, thus making them available to all CSA code.
      
      Structs are now defined in a new header csa-types-tq.h as free-standing
      types with the prefix "TorqueStruct".
      
      This is a preparation for generating per Torque-file instead of per
      namespace.
      
      Change-Id: I60fadc493a63f85d1d340768ec6f11ae47be0cb8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628787
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61865}
      19d8bfa5
  2. 20 May, 2019 1 commit
  3. 16 May, 2019 1 commit
  4. 14 May, 2019 2 commits
  5. 07 May, 2019 2 commits
    • 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
    • Simon Zünd's avatar
      [torque] Introduce is_user_defined flag for Torque macros · 17e7cf55
      Simon Zünd authored
      The Torque compiler generates macros for accessing fields in classes.
      These are currently indistiguishable from user defined macros. To
      improve the upcoming symbol search in the Torque Language Server, this
      CL introduces a flag on macros to differentiate user defined and auto
      generated macros.
      
      R=sigurds@chromium.org
      
      Bug: v8:7793
      Change-Id: I84a8ab14535ec779494b5b2e887fda8fc4edf3e5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1598688Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61261}
      17e7cf55
  6. 06 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Better SourcePositions for declarables · 9b30bdb4
      Simon Zünd authored
      This CL improves SourcePosition support inside the Torque compiler.
      It starts with the parser, where the SourcePosition of the
      MatchedInput now encompasses all tokens, not just the first one.
      
      Second, AST nodes can now be created with an explicit source position.
      This can be used to forward the "all encompassing" source position
      via MatchedInput -> ParseResultIterator to AST nodes.
      
      Third, declarables are extended to hold two different SourcePositions:
        - One represents the whole declarable. For a macro this would
          inlcude the body as well as the signature.
        - The other is the SourcePosition of the identifying part of a
          declarable. In most cases this is the name. For the rest this
          will stay invalid.
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Bug: v8:7793
      Change-Id: I509f83aeef7a040d0ea6363b5b7c31ff1b11f47b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591600
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61234}
      9b30bdb4
  7. 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
  8. 04 Mar, 2019 1 commit
  9. 01 Mar, 2019 1 commit
  10. 27 Feb, 2019 1 commit
  11. 13 Feb, 2019 1 commit
  12. 04 Feb, 2019 1 commit
  13. 28 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Compile and error check all inlined macros · 7215f6d6
      Daniel Clifford authored
      Previously, macros that returned true for "ShouldBeInlined" were only
      compiled if they were called, which made it impossible to
      type/semantic check all Torque code (e.g. newly added methods to
      structs). One might argue that all code should be tested (and thus
      through inlining compiled), but for prototyping, the skipped
      compilations were definitely annoying.
      
      As part of this change, added a ShouldGenerateExternalCode method to
      declarables (by default returns !ShouldBeInlined) that makes it
      possible to suppresses C++ code generation for any method. To
      support this at the lowest level, a NullOStream classes is added as
      part of this patch.
      
      Finally, added support for generating C++ for passing structs as label
      parameters to run previously inlined methods through the
      implementation-visitor for non-inlined compilation.
      
      Bug: v8:7793
      Change-Id: I8ce23382e12ddc25f46222c25729c82433040a73
      Reviewed-on: https://chromium-review.googlesource.com/c/1434378
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59134}
      7215f6d6
  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 1 commit
  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. 02 Jan, 2019 1 commit
  18. 05 Dec, 2018 1 commit
  19. 22 Nov, 2018 1 commit
  20. 21 Nov, 2018 2 commits
  21. 14 Nov, 2018 1 commit
  22. 13 Nov, 2018 1 commit
  23. 05 Nov, 2018 3 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] qualified access to CSA assemblers · 23b48920
      Tobias Tebbi authored
      No longer use inheritance to associate Torque-generated assemblers
      with corresponding CSA subclasses. Instead, all references to CSA
      and CSA-derived assemblers are now explicitly qualified, by generating
      a short-lived assembler instance in-place. As a consequence, Torque
      files have to mention the assembler external macros live in.
      The CodeStubAssembler is the default for this and can be omitted.
      As a drive-by cleanup, also distinguish between names that are emitted
      in C++ and names that are intended to be read in error messages. This
      is relevant for generic instantiations, where the generated names are
      rather unreadably mangled.
      
      As a follow-up, it will be easy to allow for qualified access to
      different modules, thus implementing full namespace semantics for
      modules.
      
      Bug: v8:7793
      Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950
      Reviewed-on: https://chromium-review.googlesource.com/c/1309636
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57235}
      23b48920
    • 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
  24. 29 Oct, 2018 1 commit
  25. 15 Oct, 2018 1 commit
  26. 04 Oct, 2018 1 commit
  27. 21 Sep, 2018 1 commit
  28. 18 Sep, 2018 1 commit
  29. 07 Aug, 2018 1 commit
  30. 19 Jul, 2018 1 commit
  31. 17 Jul, 2018 2 commits
    • Daniel Clifford's avatar
      [torque]: Implement structs · 1062ffb9
      Daniel Clifford authored
      Struct are bundles of value types. They are essentially just shorthand
      for passing around a group of individually defined values.
      
      Struct types are declared like this:
      
        struct A {
          x: Smi;
          y: int32;
        }
      
      and can be constructed explicitly like this:
      
        A{0, 0}
      
      Structs can be used wherever other types are used (e.g. variables,
      parameters, return values) except for parameter/return types of
      builtins and runtime functions.
      
      Struct use field access notation to set/get their values like this:
      
        let a: A = A{0, 0};
        let b: Smi = a.x;
        a.y = 0;
      
      Change-Id: I9fd36a6514c37882831256a49a50809c5db75b56
      Reviewed-on: https://chromium-review.googlesource.com/1122133
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54501}
      1062ffb9
    • Simon Zünd's avatar
      [torque] Add local const bindings · b95def34
      Simon Zünd authored
      This CL adds local const bindings. This means that instead of
      generating TVARIABLEs for variables, we can generate simple TNodes.
      
      Example:
      
      macro FooBar(): {
        const kSomeSmi: Smi = 10;
        ...
      }
      
      This CL also enforces that variables with a constexpr type are bound
      using 'const' and not 'let'.
      
      R=tebbi@chromium.org
      
      Bug: v8:7793
      Change-Id: Id20a18149df9fc374ce718bdb1478e3eabb6e6df
      Reviewed-on: https://chromium-review.googlesource.com/1138316
      Commit-Queue: Simon Zünd <szuend@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54479}
      b95def34
  32. 16 Jul, 2018 1 commit