1. 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
  2. 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
  3. 04 Mar, 2019 1 commit
  4. 13 Feb, 2019 1 commit
  5. 04 Feb, 2019 1 commit
  6. 02 Jan, 2019 1 commit
  7. 23 Nov, 2018 1 commit
  8. 19 Nov, 2018 1 commit
  9. 14 Nov, 2018 1 commit
  10. 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
  11. 29 Oct, 2018 1 commit
  12. 15 Oct, 2018 1 commit
  13. 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
  14. 04 Oct, 2018 1 commit
  15. 24 Jul, 2018 1 commit
  16. 17 Jul, 2018 1 commit
    • 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
  17. 26 Jun, 2018 1 commit
  18. 06 Jun, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Implement parameter overloading in generics · 06f2a5c2
      Daniel Clifford authored
      This allows redifinitions of generics with the same name but differing parameter
      type lists, e.g.
      
        macro coerce<Dest: type>(from: HeapObject): Dest;
        coerce<int32>(from: HeapObject): int32 {...}
        macro coerce<Dest: type>(from: Smi): Dest;
        coerce<int32>(from: Smi): int32 {...}
      
      In order to allow multiple overloads of generic macros with the same name,
      a more nuanced lookup of calls has been implemented using the
      ParameterDifference utility class. There is still work to be done to unify
      when ParameterDifference is used for lookup (e.g. removing it from operator
      lookup when operators become simple aliases for macro names), but that work
      will be done in a separate CL.
      
      As part of this CL, the custom handling of "cast<>" operator in the .g4
      grammar has been removed and replaced by a handful of equivalent overloads of
      a generic "cast" macro.
      
      Bug: v8:7793
      Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8
      Reviewed-on: https://chromium-review.googlesource.com/1087873
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53562}
      06f2a5c2
  19. 25 May, 2018 1 commit
  20. 16 May, 2018 1 commit
  21. 08 May, 2018 1 commit