1. 21 Sep, 2018 1 commit
  2. 18 Sep, 2018 1 commit
  3. 11 Sep, 2018 1 commit
  4. 07 Aug, 2018 1 commit
  5. 27 Jul, 2018 1 commit
  6. 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
  7. 16 Jul, 2018 1 commit
  8. 13 Jul, 2018 1 commit
  9. 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
  10. 02 Jul, 2018 1 commit
  11. 21 Jun, 2018 1 commit
  12. 15 Jun, 2018 1 commit
  13. 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
  14. 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
  15. 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
  16. 22 May, 2018 1 commit
  17. 18 May, 2018 1 commit
  18. 16 May, 2018 3 commits
  19. 13 May, 2018 1 commit
  20. 08 May, 2018 1 commit
  21. 07 May, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] 'bool' is now 'true|false' not 'yes|no' · dd5cdcee
      Daniel Clifford authored
      In the process, rename Boolean constants (i.e. JavaScript constants),
      to 'True' and 'False'. This uncovered a bug in the internal handling
      of True/False labels was fixed (they shouldn't be Values and Torque
      shouldn't conflate Labels with other Declarables, throwing exceptions
      when they're improperly used in the wrong context). Furthermore,
      the internal labels used for True and False for if statements
      have been renamed so that they can't be aliased from user Torque code.
      
      Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c
      Reviewed-on: https://chromium-review.googlesource.com/1044370Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53026}
      dd5cdcee
  22. 03 May, 2018 1 commit
    • Daniel Clifford's avatar
      Refactor/cleanup various Torque classes, inclduing making Type a Declarable · 90415437
      Daniel Clifford authored
      This is a preparatory step for implementing generics. Along the way, clean up
      and encapsulate a bunch of code, including:
      
      * Fully encapsulate Scope by adding the new class ScopeChain that provide an
        abstraction for creating and activating scopes.
      * Untangle Modules and Scopes.
      * Unify scope activation so that it is always associated with an AST node
        and triggered by a RAII helper class.
      * Unify (somewhat) how builtins and macros are created, fixing a few
        inconsistencies with when and how parameters and their types are declared.
      * Create a new Declarations class that brokers between the visitor classes and
        the ScopeChain. This moves handling of declaration-related errors out of the
        visitors but also makes it possible to do so without polluting Scope and
        ScopeChain with details about resolving SourcePositions in error cases.
      
      Change-Id: I180017d4cf39ccf5ef1d20b84f53284c252f8d87
      Reviewed-on: https://chromium-review.googlesource.com/1038504
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52947}
      90415437