1. 30 Sep, 2021 1 commit
  2. 23 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add LazyNode support · ede27407
      Seth Brenith authored
      This change adds a new abstract type Lazy<T> which can be used to
      interoperate with CSA code that uses LazyNode. This new type has special
      code-generation rules because its generated type is not TNode<...> but
      std::function<TNode<...>()>. Torque code can do nothing with this type
      except pass it around, but passing it to the CSA function RunLazy is an
      easy way to execute the std::function and get back a normal value.
      Torque code can also create Lazy<T> values using the intrinsic function
      %MakeLazy, which takes the name of a macro as its first parameter,
      followed by arguments to that macro which will be passed when the
      LazyNode is evaluated. We use the macro's name because the language
      doesn't support taking references to macros, and implementing such a
      feature would be complicated.
      
      Bug: v8:7793
      Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72964}
      ede27407
  3. 19 Jan, 2021 1 commit
  4. 19 Nov, 2020 1 commit
  5. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  6. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  7. 28 Sep, 2020 1 commit
  8. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  9. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  10. 05 Aug, 2020 1 commit
  11. 16 Jul, 2020 1 commit
  12. 10 Jul, 2020 2 commits
  13. 23 Jun, 2020 1 commit
    • Daniel Clifford's avatar
      [torque] generate Cast<> macros from Torque-defined classes · 1052dfb3
      Daniel Clifford authored
      This change enables automatic generation of Cast<> operators for
      classes that are defined in Torque.
      
      * Cast<> macros are generated for all classes that are defined in
        Torque code that are neither shapes nor marked with a new
        @doNotGenerateCast annotation.
      
      * Implicitly generated Cast macros simply call through to an
        internally-defined "DownCastForTorqueClass" macro that implements
        the cast using one of three strategies for efficiency. If the class
        has subclasses (i.e. a range of instance types including subtypes),
        the DownCastForTorqueClass checks for inclusion in the instance type
        range. If the class has a single instance type (i.e. no subclasses),
        then either 1) a map check is used if the class has a globally-
        defined map constant or 2) an equality check for the instance type
        is used.
      
      * Added new intrinsics to introspect class information, e.g. fetching
        instance type ranges for a class, accessing the globally-defined map
        for a class.
      
      * Removed a whole pile of existing explicit Cast<> operators that are
        no longer needed because of the implicitly generated Cast<> macros.
      
      * Added tests for the new Cast<> implementations.
      
      Bug: v8:7793
      Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68478}
      1052dfb3
  14. 22 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Generate better code when using `&` operator on bitfields · 98438d86
      Seth Brenith authored
      Sometimes CSA code carefully constructs a mask to check several
      bitfields at once. Thus far, such a check has been very awkward to write
      in Torque. This change adds a way to do so, using the
      non-short-circuiting binary `&` operator. So now you can write an
      expression that depends on several bitfields from a bitfield struct,
      like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value),
      and it will be reduced to a single mask and equality check. To
      demonstrate a usage of this new reduction, this change ports the trivial
      macro IsSimpleObjectMap to Torque. I manually verified that the
      generated code for the builtin SetDataProperties, which uses that macro,
      is unchanged.
      
      Bug: v8:7793
      Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67948}
      98438d86
  15. 08 May, 2020 1 commit
  16. 28 Apr, 2020 1 commit
  17. 23 Apr, 2020 1 commit
  18. 18 Mar, 2020 1 commit
  19. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  20. 19 Dec, 2019 1 commit
  21. 17 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Load and store bitfields · d5f180b7
      Seth Brenith authored
      This change implements support for reading and writing bitfields from
      Torque code, and adds a couple of unit tests for this functionality. As
      Tobias suggested, the LocationReference for a bitfield access contains
      a nested LocationReference to where the bitfield struct is stored, so
      that store operations can read the original value, update part of it,
      and write it back.
      
      Bug: v8:7793
      Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65487}
      d5f180b7
  22. 09 Sep, 2019 1 commit
    • Tom Tan's avatar
      Avoid defining class name `Label` as type alias in cctest because it is used by V8 · 8d107684
      Tom Tan authored
      It is not recommended to define type alias in C++ header file. cctest defines
      type alias `using Label=CodeAssemblerLabel` in anonymous namespace under
      namespace `v8::internal::compiler` in test-code-assembler.cc. This is fine
      because this type alias is expected to take effect only in this .cc file. But in
      jumbo build, multiple source files are combined as a single one, and the
      previous `Label` type alias could shadow definition of `Label` from other header
      file (for example, v8/src/codegen/label.h which is included by another .cc file)
      This is totally unexpected and triggers bad class layout and accessing in the
      latter .cc file for the places where `Label` is referenced.
      
      This change fixes cctest from Windows ARM64 jumbo build, but it applies to
      other architectures too.
      
      Bug: chromium:893460
      Change-Id: Ib2e9df76f6e3371b3940649668c5d13e6b36f028
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1788537Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63605}
      8d107684
  23. 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
  24. 23 Aug, 2019 1 commit
  25. 22 Aug, 2019 1 commit
  26. 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
  27. 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
  28. 30 Jul, 2019 1 commit
  29. 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
  30. 18 Jun, 2019 1 commit
    • 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
  31. 17 Jun, 2019 1 commit
  32. 14 Jun, 2019 2 commits
  33. 12 Jun, 2019 1 commit
  34. 06 Jun, 2019 1 commit
  35. 05 Jun, 2019 1 commit
  36. 27 May, 2019 2 commits
    • 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
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae