1. 24 Oct, 2019 1 commit
  2. 30 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add HeapSlice location references to Torque · cbf01502
      Georg Schmid authored
      This CL adds a LocationReference specifically for slices to Torque. This allows us to safely reference arrays in objects and pass around such references. For an array of T-typed elements, referencing yields a Slice<T>. In addition, the traditional element access syntax ('o.array[i]') now internally produces a slice, indexes it at 'i' and dereferences the resulting HeapReference.
      
      Bug: v8:7793
      Change-Id: I4af58e4d2feac547c55a1f6f9350a6c510383df2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771782
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63479}
      cbf01502
  3. 26 Aug, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] introduce JSAny type for user-accessible JavaScript values" · 1ef99b93
      Tobias Tebbi authored
      Changes in the reland: Rebased and added a check that JavaScript-linkage
      builtins use JSAny in parameters and return type, plus the necessary
      cleanups for this test to pass.
      
      Design Doc: https://docs.google.com/document/d/1z6j0pWHnNIfId0v00uWN2HBrGRDJxJfYuCr5K7Kr1xA
      
      This reverts commit 4418a7b9.
      
      Original change's description:
      > Revert "[torque] introduce JSAny type for user-accessible JavaScript values"
      >
      > This reverts commit 79b00555.
      >
      > Reason for revert: needs more discussion
      >
      > Original change's description:
      > > [torque] introduce JSAny type for user-accessible JavaScript values
      > >
      > > This CL introduces a JSAny type for user-exposed JavaScript values and
      > > a few new types to define it. Especially, it splits Symbol into
      > > PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      > > symbols).
      > >
      > > The change is mostly mechanical, but a few things are interesting:
      > > - PropertyKey and JSPrimitive were designed to coincide with the spec
      > >   notions of IsPropertyKey() and primitive value, respectively.
      > > - Since Name is an open type, we define AnyName to be the known
      > >   subtypes of Name. This is not too elegant, but by using AnyName
      > >   instead of Name, typeswitch can properly conclude something if a
      > >   subtype of Name is excluded.
      > >
      > > Small drive-by changes, which were necessary:
      > > - Allow subtyping on label parameters.
      > > - Fix the formatting of typeswitch, it was broken with union types
      > >   in case types.
      > >
      > > Bug: v8:7793
      > > Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63114}
      >
      > TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      >
      > Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:7793
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63115}
      
      TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:7793
      Change-Id: Icca34e3824f55009b984d9348fd21884400f0081
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769316
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63395}
      1ef99b93
  4. 23 Aug, 2019 1 commit
  5. 21 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add user-defined Slice struct · 26e39d12
      Georg Schmid authored
      This CL consists of several preparatory steps for slices in Torque. Above all, it introduces a user-defined struct, torque_internal::Slice<T>, that performs bounds checking and returns references to elements in arrays. To enable this, several smaller changes were also made:
      
      - Constructors of internal classes such as torque_internal::Reference<T> now require a special 'Unsafe' argument, making it clear that there be dragons.
      - Struct methods are now declared during finalization. This allows instances of generic structs to have methods referring to the same struct. Previously, methods would be declared before the instance had been fully registered, leading to errors during type resolution. Furthermore, such methods were declared in a temporary namespace, that would then erroneously escape and lead to use-after-free issues.
      - Instances of TypeArgumentInference were not running in the correct (Torque) scopes, leading to type resolution errors.
      - The chain of ContextualVariable::Scope for any given ContextualVariable (such as CurrentScope) can now be walked, simplifying debugging.
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Bug: v8:7793
      Change-Id: I36f808f63cc3ce441062dfc56f511f24f1e3121e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758322
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63314}
      26e39d12
  6. 12 Aug, 2019 1 commit
  7. 07 Aug, 2019 2 commits
    • Tobias Tebbi's avatar
      Revert "[torque] introduce JSAny type for user-accessible JavaScript values" · 4418a7b9
      Tobias Tebbi authored
      This reverts commit 79b00555.
      
      Reason for revert: needs more discussion
      
      Original change's description:
      > [torque] introduce JSAny type for user-accessible JavaScript values
      > 
      > This CL introduces a JSAny type for user-exposed JavaScript values and
      > a few new types to define it. Especially, it splits Symbol into
      > PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      > symbols).
      > 
      > The change is mostly mechanical, but a few things are interesting:
      > - PropertyKey and JSPrimitive were designed to coincide with the spec
      >   notions of IsPropertyKey() and primitive value, respectively.
      > - Since Name is an open type, we define AnyName to be the known
      >   subtypes of Name. This is not too elegant, but by using AnyName
      >   instead of Name, typeswitch can properly conclude something if a
      >   subtype of Name is excluded.
      > 
      > Small drive-by changes, which were necessary:
      > - Allow subtyping on label parameters.
      > - Fix the formatting of typeswitch, it was broken with union types
      >   in case types.
      > 
      > Bug: v8:7793
      > Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63114}
      
      TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63115}
      4418a7b9
    • Tobias Tebbi's avatar
      [torque] introduce JSAny type for user-accessible JavaScript values · 79b00555
      Tobias Tebbi authored
      This CL introduces a JSAny type for user-exposed JavaScript values and
      a few new types to define it. Especially, it splits Symbol into
      PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
      symbols).
      
      The change is mostly mechanical, but a few things are interesting:
      - PropertyKey and JSPrimitive were designed to coincide with the spec
        notions of IsPropertyKey() and primitive value, respectively.
      - Since Name is an open type, we define AnyName to be the known
        subtypes of Name. This is not too elegant, but by using AnyName
        instead of Name, typeswitch can properly conclude something if a
        subtype of Name is excluded.
      
      Small drive-by changes, which were necessary:
      - Allow subtyping on label parameters.
      - Fix the formatting of typeswitch, it was broken with union types
        in case types.
      
      Bug: v8:7793
      Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63114}
      79b00555
  8. 05 Aug, 2019 1 commit
  9. 02 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Infer type arguments of generic struct initializers · b1db8d84
      Georg Schmid authored
      Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
      
        struct Box<T: type> {
          const value: T;
        }
      
      one would initialize a new box using
      
        const aSmi: Smi = ...;
        const box = Box<Smi> { value: aSmi };
      
      With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
      
      Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
      
      R=jgruber@chromium.org, tebbi@chromium.org
      
      Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63036}
      b1db8d84
  10. 31 Jul, 2019 1 commit
  11. 30 Jul, 2019 1 commit
  12. 26 Jul, 2019 1 commit
  13. 23 Jul, 2019 1 commit
    • Georg Schmid's avatar
      [torque] Add Generic Structs · 1d9a5d88
      Georg Schmid authored
      This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType.
      
      As an example, consider a Tuple of types T1, T2:
      
        struct Tuple<T1: type, T2: type> {
          const fst: T1;
          const snd: T2;
        }
      
      which can be manipulated using generic macros, such as
      
        macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> {
          return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst};
        }
      
      Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly:
      
        const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2};
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Change-Id: I43111561cbe53144db473dc844a478045644ef6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62878}
      1d9a5d88
  14. 21 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Support 'real' internal classes · 76c1e829
      Sigurd Schneider authored
      Rework the implementation of non-external Torque classes to use
      Struct machinery rather than FixedArray machinery. This allows
      Torque-only defined 'internal' classes to the automatically generate
      class verifiers and printers.
      
      As part of this change, generate C++ boilerplate accessors for
      internal Torque classes, since this is a pre-requisite for the
      verifiers, printers and other Struct-based functionality.
      
      Moreover, augment the header-generating functionality in Torque
      to create separate header files for field offset definitions,
      internal class C++ definitions and instance types.
      
      Bug: v8:7793
      Change-Id: I47d5f1570040c2b44d378f23b6cf95d3d132dacc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607645
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62317}
      76c1e829
  15. 19 Jun, 2019 1 commit
  16. 18 Jun, 2019 2 commits
    • Seth Brenith's avatar
      [torque] Address remaining usages of @noVerifier in base.tq · e620ba13
      Seth Brenith authored
      For every @noVerifier in base.tq, this change either removes it or
      ensures that it has some annotation explaining why it can't be removed.
      The @noVerifier usages that can't be removed fall into the following
      categories:
      1. Classes that don't have their own instance types and therefore have
         no meaningful way to do an Is...() check
      2. Fields that might not exist
      3. Fields that are waiting for MaybeObject support in Torque
      
      Bug: v8:9311
      Change-Id: Id452d4151ec07347ae96a9b5f3b26e2ac8065d31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659134Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#62263}
      e620ba13
    • Georg Schmid's avatar
      [csa] Track stores and perform simple alias analysis in CSA Load Elimination · 16893bda
      Georg Schmid authored
      This CL allows CsaLoadElimination to retain some information in the presence of StoreToObject nodes. Two stores to an object don't alias if either the objects or the offsets don't alias. The analysis approximates either of these two conditions conservatively as follows:
      - Freshly allocated, distinct objects cannot alias.
      - Two objects cannot alias if one of is freshly allocated and the other was passed as a parameter or is a heap constant.
      - Two offsets cannot alias if they are both constant and distinct from each other.
      
      R=jarin@chromium.org, tebbi@chromium.org
      
      Change-Id: Ibec81913b413f81a3f7cbd40544a22d3711e6e5a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660626
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62232}
      16893bda
  17. 17 Jun, 2019 1 commit
  18. 14 Jun, 2019 2 commits
  19. 12 Jun, 2019 1 commit
  20. 11 Jun, 2019 2 commits
  21. 06 Jun, 2019 2 commits
  22. 30 May, 2019 1 commit
  23. 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
  24. 24 May, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland^2 "[torque] move class tests to unittests" · d47db126
      Tobias Tebbi authored
      This is a reland of c33a1ef2
      
      It seems the revert was based on a flake.
      
      Original change's description:
      > Reland "[torque] move class tests to unittests"
      >
      > This is a reland of f589d561
      >
      > Now with an ASAN-container-overflow false positive workaround:
      > Somehow ASAN was unhappy about a simple
      > std::vector<std::string>::push_back.
      > Increasing the std::vector capacity before doing the push_back
      > strangely fixes the problem.
      >
      > Original change's description:
      > > [torque] move class tests to unittests
      > >
      > > This avoids the generation of fake external classes.
      > >
      > > Bug: v8:7793
      > > Change-Id: I9744b299d3ec474d72b298b4f6143f95e345d1d9
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1625991
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#61778}
      >
      > TBR: szuend@chromium.org, sigurds@chromium.org
      > Bug: v8:7793
      > Change-Id: Ifa1958e4d6e850ba27632aa95c7efaf5ca4bfefa
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627970
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61807}
      
      Bug: v8:7793
      Change-Id: Ia403f1b784500c0903172f13e74c0b325e82599f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627980Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61819}
      d47db126
  25. 23 May, 2019 4 commits
  26. 21 May, 2019 1 commit
  27. 20 May, 2019 1 commit
  28. 16 May, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Move Map layout definition to Torque · 15a7e04e
      Seth Brenith authored
      This commit attempts to change as little behavior as possible, but it
      does require reordering the fields within Map to abide by Torque rules
      specifying that strong and weak fields must be in separate sections.
      
      Also includes some Torque compiler updates:
      - Allow enums (types extending from integral types) as class fields
      - Rename @ifdef to @if and add @ifnot for inverse checks
      - Allow void fields in class declarations, which take up no space and
        emit no accessors
      
      Bug: v8:8952
      Change-Id: I1de6f34c1b15ed87d718666a05176980a218e97c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1480919
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61588}
      15a7e04e
  29. 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
  30. 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
  31. 08 May, 2019 1 commit
  32. 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