1. 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
  2. 20 May, 2019 1 commit
  3. 16 May, 2019 2 commits
  4. 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
  5. 13 May, 2019 4 commits
  6. 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
  7. 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
  8. 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
  9. 09 Apr, 2019 1 commit
  10. 27 Feb, 2019 1 commit
  11. 20 Feb, 2019 1 commit
  12. 18 Feb, 2019 1 commit
  13. 06 Feb, 2019 1 commit
  14. 04 Feb, 2019 1 commit
  15. 31 Jan, 2019 1 commit
  16. 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
  17. 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
  18. 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
  19. 17 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  20. 23 Nov, 2018 1 commit
  21. 22 Nov, 2018 1 commit
  22. 21 Nov, 2018 2 commits
  23. 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
  24. 13 Nov, 2018 1 commit
  25. 05 Nov, 2018 1 commit
    • 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
  26. 29 Oct, 2018 1 commit
  27. 15 Oct, 2018 1 commit
  28. 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
  29. 04 Oct, 2018 1 commit
  30. 06 Sep, 2018 1 commit
  31. 08 Aug, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] add typeswitch statement · 91ef86f9
      Tobias Tebbi authored
      This adds a typeswitch statement
      
      typeswitch (e)
      case (x1 : Type1) {
        ...
      } case (x2 : Type2) {
      
      } ...
      ... case (xn : TypeN) {
        ...
      }
      
      This checks to which of the given types the result of evaluating e can
      be cast, in the order in which they are listed. So if an earlier
      type matches, a value of this type won't reach a later case.
      
      The type-checks are performed by calling the cast<T>() macro.
      The type of the argument passed to the cast macro is dependent on the
      case and excludes all types checked earlier. For example, in
      
      const x : Object = ...
      typeswitch (x)
      case (x : Smi) {
        ...
      } case (x : HeapNumber) {
        ...
      } case (x : HeapObject) {
        ...
      }
      
      there will be calls to cast<Smi>(Object) and
      cast<HeapNumber>(HeapObject), because after the Smi check we know that
      x has to be a HeapObject. With the refactored base.tq definition of
      cast, this will generate efficient code and avoid repeating the Smi
      check in the second case.
      
      The type system ensures that all cases are reachable and that the type
      given to the last case is safe without a runtime check (in other words,
      the union of all checked types covers the type of e).
      
      The cases can also be written as
      case (Type) { ... }
      , in which case the switched value is not re-bound with the checked
      type.
      
      Bug: v8:7793
      Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3
      Reviewed-on: https://chromium-review.googlesource.com/1156506
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54958}
      91ef86f9
  32. 07 Aug, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] generate implicit_cast according to VisitResult types · 46952216
      Tobias Tebbi authored
      In the generated CSA, we called overloaded macros while relying on CSA
      subtyping of TNodes. This doesn't work well with overloads, because
      for C++ any TNode subtyping is treated as an implicit conversion, which
      makes these calls ambiguous for C++.
      As a solution, we insert implicit_cast conversions for arguments
      according to the type predicted by Torque. This way, a CSA overload is always
      called with exactly the signature declared in base.tq.
      This has the additional benefit that it validates the signatures declared in
      base.tq, which could previously be too permissive.
      Also, this triggered a bug in structs, where VisitResult's were
      carrying the wrong type.
      
      Bug: v8:7793
      TBR: danno@chromium.org
      Change-Id: I8ed4bfd04793c8a8805a4a3dd5cf2a85c20ce786
      Reviewed-on: https://chromium-review.googlesource.com/1165237
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54948}
      46952216
  33. 20 Jul, 2018 1 commit