1. 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
  2. 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
  3. 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
  4. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored
      This CL is pretty mechanical; I just iterated through some Torque
      classes making the following changes:
      
      - Use @generateCppClass if it seems easy to
      - Use @generatePrint if the existing printer doesn't do anything special
      - Fix up any imprecise field types
      
      It also includes two minor changes to implementation-visitor:
      
      - Add a new -inl.h file with the things needed for
        torque-generated/class-definitions-tq.cc so we don't need to keep
        changing the compiler when we add @generateCppClass.
      - Avoid emitting incorrect accessors for ExternalPointers. This isn't
        strictly necessary for correctness, as the accessors defined in C++
        already hide the ones inherited from generated code, but it makes me
        feel safer.
      
      Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  5. 21 Feb, 2020 1 commit
  6. 09 Oct, 2019 1 commit
  7. 12 Sep, 2019 1 commit
  8. 19 Jul, 2019 1 commit
  9. 28 Jun, 2019 1 commit
  10. 17 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 2 · 15ea19db
      Seth Brenith authored
      This change removes the special case in the Torque compiler for types
      that descend from JSObject: they will no longer get implicit
      "| Undefined" appended to their types for verification purposes. It
      removes any additional custom verification steps in objects-debug that
      are made redundant by that change.
      
      In order to do so safely, I categorized all cases where we were
      implicitly adding "| Undefined" to the field type, as follows:
      
      1. Classes that aren't using the generated verifier function (we should
         probably revisit these, but for now we at least know they're safe):
         - JSGlobalObject
         - JSFinalizationGroup
         - JSFinalizationGroupCleanupIterator
      
      2. Classes where the existing verifier is already at least as strict as
         what we would get after removing the implicit "| Undefined":
         - JSDate
         - JSPromise
         - JSRegExp
         - JSRegExpStringIterator
         - WasmMemoryObject
         - JSWeakRef
         - JSStringIterator
         - WasmExceptionObject
         - JSListFormat (fixed in part 1)
         - JSPluralRules (fixed in part 1)
         - JSRelativeTimeFormat (fixed in part 1)
         - JSSegmenter (fixed in part 1)
         - JSArrayBufferView (fixed in part 1)
         - JSTypedArray (fixed in part 1)
      
      3. Classes where, to the best of my knowledge based on code inspection,
         we already initialize the object correctly to pass the new stricter
         generated verifier:
         - JSFunction
         - JSArrayIterator
         - JSMessageObject
         - JSBoundFunction
         - JSAsyncFromSyncIterator
         - WasmModuleObject
         - JSAsyncFunctionObject
      
      4. Classes that needed some adjustment to their initialization order to
         avoid exposing uninitialized state to the GC:
         - JSArray (only in Factory::NewJSArray; Runtime_NewArray and
                    CodeStubAssembler::AllocateJSArray already behave fine)
         - WasmTableObject
         - JSDateTimeFormat
         - JSNumberFormat
         - JSCollator
         - JSV8BreakIterator
         - JSLocale
         - JSSegmentIterator
         - JSModuleNamespace
      
      5. Classes that had incorrect type definitions in Torque:
         - WasmGlobalObject (category 4 after correction)
      
      6. Classes that weren't fully initialized due to bugs:
         - JSGeneratorObject
         - JSAsyncGeneratorObject
      
      Bug: v8:9311
      Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62228}
      15ea19db
  11. 05 Jun, 2019 1 commit
    • Suraj Sharma's avatar
      Reland "[torque] Convert few class layout to torque." · 8dc7da0c
      Suraj Sharma authored
      This is a reland of 42fee61a
      
      The in-object fields of JSModuleNamespace has been excluded from torque.
      It is restored back to its existing mechanism on the C++ side and rest
      of the class is ported to torque.
      
      Original change's description:
      > [torque] Convert few class layout to torque.
      >
      > 1. Converted Module, JSModuleNameSpace, JSCollator, JSV8BreakIterator,
      >       TemplateList,
      >       JSStrictArgumentsObject to torque.
      >
      > Bug: v8:8952
      > Change-Id: I01e88ac36acd7ba18791bec609e5ae737672c731
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619146
      > Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61671}
      
      Bug: v8:8952
      Change-Id: Ibd41000ad96ae57bd4f452f0c0c1b890e2c6fb5c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632833Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#62005}
      8dc7da0c
  12. 23 May, 2019 1 commit
  13. 21 May, 2019 1 commit
    • Georg Neis's avatar
      Revert "Reland "[torque] Convert few class layout to torque."" · e165213e
      Georg Neis authored
      This reverts commit 42fee61a.
      
      Reason for revert: it's not safe to access in-object fields that way.
      Will post more information in Gerrit.
      
      Original change's description:
      > Reland "[torque] Convert few class layout to torque."
      > 
      > This is a reland of b9bfd006
      > 
      > Original change's description:
      > > [torque] Convert few class layout to torque and updated torque code formatter.
      > >
      > > 1. Converted Module, JSModuleNameSpace, JSCollator, JSV8BreakIterator,
      > >       TemplateList,
      > >       JSStrictArgumentsObject to torque.
      > > 2. Updated torque code formatter to now handle multi-line
      > >             declarations correctly.
      > >
      > > Bug: v8:8952
      > > Change-Id: I97846b1bc0d2cba5d7a68468fc263423b1b55d19
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536988
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      > > Cr-Commit-Position: refs/heads/master@{#61624}
      > 
      > Removed the Torque code Formatter update from this CL
      > 
      > Bug: v8:8952
      > Change-Id: I01e88ac36acd7ba18791bec609e5ae737672c731
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619146
      > Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61671}
      
      TBR=surshar@microsoft.com,szuend@chromium.org
      
      Change-Id: I6fd66ce67aeecf0128878924d5e5b6a71ad88e32
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8952
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1622109Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61692}
      e165213e
  14. 20 May, 2019 1 commit
    • Suraj Sharma's avatar
      Reland "[torque] Convert few class layout to torque." · 42fee61a
      Suraj Sharma authored
      This is a reland of b9bfd006
      
      Original change's description:
      > [torque] Convert few class layout to torque and updated torque code formatter.
      >
      > 1. Converted Module, JSModuleNameSpace, JSCollator, JSV8BreakIterator,
      >       TemplateList,
      >       JSStrictArgumentsObject to torque.
      > 2. Updated torque code formatter to now handle multi-line
      >             declarations correctly.
      >
      > Bug: v8:8952
      > Change-Id: I97846b1bc0d2cba5d7a68468fc263423b1b55d19
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536988
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#61624}
      
      Removed the Torque code Formatter update from this CL
      
      Bug: v8:8952
      Change-Id: I01e88ac36acd7ba18791bec609e5ae737672c731
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619146
      Commit-Queue: Suraj Sharma <surshar@microsoft.com>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61671}
      42fee61a
  15. 18 May, 2019 1 commit
  16. 17 May, 2019 1 commit
  17. 04 Apr, 2019 1 commit
  18. 13 Feb, 2019 1 commit
  19. 07 Feb, 2019 1 commit
  20. 09 Jan, 2019 1 commit
  21. 17 Dec, 2018 1 commit
  22. 08 Dec, 2018 1 commit
  23. 27 Nov, 2018 1 commit
  24. 22 Nov, 2018 1 commit
  25. 01 Nov, 2018 1 commit
  26. 24 Oct, 2018 1 commit
  27. 23 Oct, 2018 1 commit
  28. 04 Oct, 2018 1 commit
  29. 29 Sep, 2018 1 commit
  30. 07 Sep, 2018 1 commit
  31. 05 Sep, 2018 2 commits