1. 06 Feb, 2019 1 commit
  2. 29 Jan, 2019 1 commit
  3. 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
  4. 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
  5. 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
  6. 02 Jan, 2019 1 commit
  7. 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
  8. 22 Nov, 2018 1 commit
  9. 21 Nov, 2018 2 commits
  10. 19 Nov, 2018 1 commit
  11. 13 Nov, 2018 1 commit
  12. 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
  13. 29 Oct, 2018 1 commit
  14. 15 Oct, 2018 1 commit
  15. 04 Oct, 2018 1 commit
  16. 27 Sep, 2018 1 commit
  17. 21 Sep, 2018 1 commit
  18. 18 Sep, 2018 1 commit
  19. 11 Sep, 2018 1 commit
  20. 07 Aug, 2018 1 commit
  21. 27 Jul, 2018 1 commit
  22. 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
  23. 16 Jul, 2018 1 commit
  24. 13 Jul, 2018 1 commit
  25. 03 Jul, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] fix variables, returns and conditionals with constexpr · 81186ff4
      Tobias Tebbi authored
      Variables/return values with constexpr type cannot have multiple
      assignments. We check this now.
      For conditionals, it is important to always infer a non-constexpr type.
      This CL adds the ability to map any type (including union types) to be
      mapped to their non-constexpr variant. Conditionals infer their type as
      the non-constexpr version of a combination of the two branch types.
      
      In addition, this improves subtyping for constexpr types:
      If A extends B, then constexpr A extends constexpr B.
      This makes it necessary to clean up "constexpr String", which has nothing
      to do with tagged values.
      
      Bug: v8:7793
      Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6
      Reviewed-on: https://chromium-review.googlesource.com/1122864
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54167}
      81186ff4
  26. 02 Jul, 2018 1 commit
  27. 21 Jun, 2018 1 commit
  28. 15 Jun, 2018 1 commit
  29. 12 Jun, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Turn implicit converts/unsafe_casts into generics · bbbfd81c
      Daniel Clifford authored
      In the process:
        - Add strict ordering of Types so that name mangling is consistent
          and build time. Previously, the UnionType stored the union's
          types in a std::set<const Type*>, which did not have a consistent
          ordering of the types in the set.
        - Add a int31 type to enable consistency and correctness of
          handling of 'constexpr int31' values on the C++ side.
        - By removing the "implicit" keyword for operators, there is now
          one less difference between operators and calls, another
          incremental step in unifying operators and calls.
        - Enable external (i.e. C++-defined) generic specializations
        - Add CSA support for checking double ElementsKinds, including
          tests.
        - Clean up some constexpr/non-constexpr handling of ElementsKinds.
      
      Bug: v8:7793
      Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8
      Reviewed-on: https://chromium-review.googlesource.com/1091155
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53664}
      bbbfd81c
  30. 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
  31. 29 May, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] add union types · bf9d2893
      Tobias Tebbi authored
      This adds support for union types to Torque.
      
      There is a new type expression
      A | B
      to form the union of the type expressions A and B.
      This is only possible if A and B have a common supertype, to prevent
      nonsensical unions of types with different representations.
      
      Union types are normalized:
      A | B == B | A
      A | (B | C) == (A | B) | C
      A | A == A
      
      The subtyping rules are defined recursively:
      (A | B) <: C  if  A <: C and B <: C
      A <: (B | C)  if  A <: B or A <: C
      
      This allows to define Object as a union type:
      
      type Tagged generates 'TNode<Object>';
      type Smi extends Tagged generates 'TNode<Smi>';
      type HeapObject extends Tagged generates 'TNode<HeapObject>';
      type Object = Smi | HeapObject;
      
      The type {Tagged} is introduced to have a common supertype of all
      tagged values, but we should not use it directly, because {Object}
      contains the additional information that there is nothing but {Smi}
      and {HeapObject} values.
      
      When mapping union types to CSA types, we select the most specific
      common supertype. For Number and Numeric, we already use union types
      on the CSA side. Since it is not possible to map to CSA union types
      in general, we special-case these two union types to map them to
      the CSA union types we already use.
      
      Bug: v8:7793
      Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908
      Reviewed-on: https://chromium-review.googlesource.com/1076132Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53411}
      bf9d2893
  32. 22 May, 2018 1 commit
  33. 18 May, 2018 1 commit
  34. 16 May, 2018 1 commit