1. 11 Mar, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Add option for printing Torque IR · ad0e581c
      Seth Brenith authored
      While working on the Torque compiler, I've sometimes found it difficult
      to understand Torque's intermediate representation and how it
      corresponds to the output. In this change, I propose adding a build flag
      that instructs Torque to emit comments describing its IR, interspersed
      in the generated code. This is particularly useful for seeing the stack
      management instructions (Peek, Poke, and DeleteRange) which don't emit
      any corresponding C++ code.
      
      Bug: v8:7793
      Change-Id: I24bdec47da76c9bd751b928d3cd92aa513dc6593
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748040Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73352}
      ad0e581c
  2. 19 Jan, 2021 1 commit
  3. 08 Dec, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Make runtime macros inlinable · 6b5f4208
      Seth Brenith authored
      Currently, all runtime C++ code generated for Torque macros all goes
      into a single .cc file and corresponding header. This is simple, but
      limits how we can use that generated code. For example, field accessors
      are generally expected to be inlinable at compilation time (not relying
      on LTO).
      
      This change updates the Torque compiler to output runtime C++ code into
      the same *-tq-inl.inc files that contain implementations of member
      functions for generated classes. All Torque macros transitively called
      from the top-level macros are included in the same file, to avoid any
      need for these generated files to #include each other. These macros are
      emitted within per-file namespaces to avoid multiple-definition build
      failures.
      
      Bug: v8:7793
      Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71664}
      6b5f4208
  4. 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
  5. 05 Oct, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Add C++ backend for Torque compiler · c7c5d50d
      Seth Brenith authored
      This change adds a new code generator, which supports a subset of the
      instructions supported by the existing CSAGenerator, and instead of
      generating CSA it generates runtime C++ code. The new generator is used
      to generate a set of Torque macros that return slices to indexed fields.
      These new macros should be sufficient to eventually support
      Torque-generated field accessors, BodyDescriptors, verifier functions,
      and postmortem field inspection in debug_helper.
      
      Bug: v8:7793
      Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70313}
      c7c5d50d
  6. 27 May, 2020 1 commit
  7. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored
      This reverts commit 4e5fabae.
      
      Reason for revert: performance regressions chromium:1085305, chromium:1084978
      
      Original change's description:
      > [torque][cleanup] Use more precise field types in a few classes
      > 
      > This change updates some Torque-defined classes to include more precise
      > field types where possible. It also updates those classes to use
      > @generateCppClass. One field was removed because it's unused
      > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
      > actually became less precise because they're based on Script::name,
      > which is an embedder-provided untyped Local<Value>. (Automatically
      > generated accessors pointed out this bug easily.)
      > 
      > This change also includes a couple of minor fixes in Torque.
      > 
      > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67907}
      
      TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  8. 19 May, 2020 1 commit
  9. 04 May, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] improve GC visitors · f1400e43
      Tobias Tebbi authored
      Summary of changes:
      
      - GC visitors no longer rely on superclass visitors, but instead visit
        everything themselves. This enables generating better code.
      - Try to match simple body descriptors to reduce the amount of generated
        code.
      - Turn SizeFor(instance) into an AllocatedSize() method.
      - Remove the special handling of resizable object sizes from Torque
        and instead overwrite AllocatedSize in classes that need special
        handling in C++.
      - Split the visitor id lists depending on whether the class has pointer
        fields.
      - Turn Torque-generated body descriptors into an .inc file to
        simplify includes.
      - Fix generated size functions to properly align the size.
      - Generate GC visitors (and C++ class definitions) for all string
        classes and FixedArray, WeakFixedArray, and WeakArrayList.
      - Store generated instance types in Torque class types. This is only
        used to determine if a type has a single instance type in this CL.
      
      Bug: v8:7793
      Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67542}
      f1400e43
  10. 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
  11. 23 Dec, 2019 1 commit
  12. 06 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Add bitfield declarations · 57074692
      Seth Brenith authored
      This change is the first part of adding Torque support for a "bitfield
      struct", which represents a set of bitfields packed together into an
      integer value. With this change, Torque can generate the list of
      BitField template specializations that allow runtime code to use the
      bitfield values. The flags used in SharedFunctionInfo are converted to
      Torque to exercise this functionality. Bitfield values are not yet
      accessible directly from Torque code.
      
      Bug: v8:7793
      Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65371}
      57074692
  13. 07 Oct, 2019 1 commit
  14. 22 Aug, 2019 1 commit
    • Simon Zünd's avatar
      Introduce "-m32" compilation mode for Torque · 4f0ee93b
      Simon Zünd authored
      Forge (Google3) can only run 64-bit executables. As Torque runs as part
      of the build process, we need a 32-bit "cross-compile" mode when
      we target 32-bit architectures. Note that this flag won't be needed
      in Chromium/V8 land, since we build V8 with the same bit width as
      the target architecture.
      
      This CL adds a new runtime flag to torque "-m32". When enabled, the
      flag forces 32-bit word sizes for various pointer/word sizes. By
      default, the host system sizes from {src/commons/globals.h}
      are used.
      
      R=tebbi@chromium.org
      
      Bug: v8:9641
      Change-Id: I8701eec45e3fb59dc65049b0a679d34589c4127f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763540
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63334}
      4f0ee93b
  15. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      Updates since original: now compressed pointers passed to the function
      GetObjectProperties are required to be sign-extended. Previously, the
      function allowed zero-extended values, but that led to ambiguity on
      pointers like 0x88044919: is it compressed or is the heap range actually
      centered on 0x100000000?
      
      Original change's description:
      > Add postmortem debugging helper library
      >
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      >
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      >
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      >
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      >
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      >
      > Bug: v8:9376
      >
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      Bug: v8:9376
      Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
  16. 24 Jul, 2019 1 commit
    • Zhi An Ng's avatar
      Revert "Add postmortem debugging helper library" · 6747e3a1
      Zhi An Ng authored
      This reverts commit 517ab73f.
      
      Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
      
      Original change's description:
      > Add postmortem debugging helper library
      > 
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      > 
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      > 
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      > 
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      > 
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      > 
      > Bug: v8:9376
      > 
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62899}
      6747e3a1
  17. 23 Jul, 2019 2 commits
    • Seth Brenith's avatar
      Add postmortem debugging helper library · 517ab73f
      Seth Brenith authored
      This change begins to implement the functionality described in
      https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      for investigating V8 state in crash dumps.
      
      This change adds a new library, v8_debug_helper, for providing platform-
      agnostic assistance with postmortem debugging. This library can be used
      by extensions built for debuggers such as WinDbg or lldb. Its public API
      is described by debug-helper.h; currently the only method it exposes is
      GetObjectProperties, but we'd like to add more functionality over time.
      The API surface is restricted to plain C-style structs and pointers, so
      that it's easy to link from a debugger extension built with a different
      toolchain.
      
      This change also adds a new cctest file to exercise some basic
      interaction with the new library.
      
      The API function GetObjectProperties takes an object pointer (which
      could be compressed, or weak, or a SMI), and returns a string
      description of the object and a list of properties the object contains.
      For now, the list of properties is entirely based on Torque object
      definitions, but we expect to add custom properties in future updates so
      that it can be easier to make sense of complex data structures such as
      dictionaries.
      
      GetObjectProperties does several things that are intended to generate
      somewhat useful results even in cases where memory may be corrupt or
      unavailable:
      - The caller may optionally provide a type string which will be used if
        the memory for the object's Map is inaccessible.
      - All object pointers are compared against the list of known objects
        generated by mkgrokdump. The caller may optionally provide the
        pointers for the first pages of various heap spaces, to avoid spurious
        matches. If those pointers are not provided, then any matches are
        prefixed with "maybe" in the resulting description string, such as
        "maybe UndefinedValue (0x4288000341 <Oddball>)".
      
      Bug: v8:9376
      
      Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62882}
      517ab73f
    • 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
  18. 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
  19. 11 Jun, 2019 3 commits
  20. 05 Jun, 2019 1 commit
  21. 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
  22. 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
  23. 17 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Always run all ImplementationVisitor steps · 8610cb5a
      Simon Zünd authored
      The language server and unit tests pass in an empty output directory
      to signal that no C++ files should be generated. As these
      generation steps include some validations, they should also be
      included in language server and unit test compilation runs.
      
      This CL introduces a "dry run" flag on the ImplementationVisitor.
      Additionaly, the implementation visitor wraps the file writing
      functionality. In case of a dry-run, file writing becomes a no-op.
      
      R=sigurds@chromium.org
      
      Bug: v8:7793
      Change-Id: Id699fdf0b35311ddd3c1f5419baa0237b40ddce4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617244Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61599}
      8610cb5a
  24. 16 May, 2019 1 commit
  25. 15 May, 2019 1 commit
    • Simon Zünd's avatar
      [torque-ls] Support types in document-wide symbol requests · d6b51cba
      Simon Zünd authored
      This CL adds support for all kinds of Types to "textDocument/symbol"
      requests. While LSP has support for classes and structs, it does not
      have support for generic types. Only classes are marked as such,
      while all other types are marked as structs in terms of the LSP.
      
      Special care has to be taken with TypeAliases. Generic call sites
      introduce a new scope (similar to namespace scopes), where new
      TypeAliases are created for Generic type arguments. These TypeAliases
      then point to the specialized type inside this call-site specific
      scope. To omit the specialized TypeAliaes from the symbols list,
      they are marked using the "is_user_defined" flag.
      
      R=sigurds@chromium.org
      
      Bug: v8:8880
      Change-Id: I576d1c677a5255d54f7774aa053f431608a4cd0c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613240
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61534}
      d6b51cba
  26. 14 May, 2019 4 commits
  27. 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
  28. 08 May, 2019 1 commit
    • Simon Zünd's avatar
      Reland "[torque] Introduce force_assert_statements compiler option" · 2e3862d7
      Simon Zünd authored
      This is a reland of 2d45ecf0
      
      The reland properly initializes struct fields in unittests. To prevent
      this in the future, TorqueCompilerOptions uses brace initialization.
      
      Original change's description:
      > [torque] Introduce force_assert_statements compiler option
      >
      > "assert(...)" statements are usually only visited and generated in
      > debug builds. To provide Language Server support for statements inside
      > asserts, the force_assert_statements option allows to manually
      > override this behavior and visit assert statements in release builds.
      >
      > R=sigurds@chromium.org
      >
      > Bug: v8:7793
      > Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180
      > Auto-Submit: Simon Zünd <szuend@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61295}
      
      Bug: v8:7793
      Change-Id: I96ef863c8c85ae87a00cbe858655d4a2c9368b41
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599599
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61315}
      2e3862d7
  29. 07 May, 2019 4 commits
  30. 25 Apr, 2019 1 commit
  31. 24 Apr, 2019 1 commit
    • Simon Zünd's avatar
      [torque] Collect lint errors for later processing · 1397697e
      Simon Zünd authored
      This CL changes lint errors to not be printed directly to stderr.
      Instead, they are collected in a list that gets surfaced via
      the TorqueCompilerResult. This is done so they can be presented
      to language server clients.
      
      This change also removes the "abort_on_lint_errors" option.
      API users can now decide for themselves what to do, depending on
      the presence of lint errors in the returned list.
      
      R=sigurds@chromium.org, tebbi@chromium.org
      
      Bug: v8:8880
      Change-Id: I44601010491aafcf4c8609fd8c115219317506a4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581608Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60983}
      1397697e