Skip to content

V
V8
Switch branch/tag
  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
  3. 29 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      Seth Brenith authored 
      This patch is mostly mechanical. A few changes in
implementation-visitor.cc might be worth mentioning:
- Don't generate both field offset macros and class definitions for the
  same class. This was mostly just to keep me from forgetting to remove
  the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
  also helpfully flagged that FixedArrayBase wasn't using the generated
  class that it requested.
- Generate forward declarations for all tq-defined classes in
  internal-class-definitions-tq.h. This is helpful for making things
  compile when classes have fields of other class types.
- When generating accessors for union types, use the nearest class type
  that contains the entire union rather than plain Object. This is
  important for compile-time type safety. It also required a few minor
  fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
  source-text-module.cc, and a correction of the field types in
  CallHandlerInfo to match how they're set in api.cc).

Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
  5. 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
  7. 17 Apr, 2019 1 commit
  9. 01 Mar, 2019 2 commits
  11. 13 Feb, 2019 1 commit
  13. 09 Jan, 2019 1 commit
  15. 20 Dec, 2018 1 commit
  17. 18 Dec, 2018 2 commits
  19. 17 Dec, 2018 1 commit
  21. 08 Dec, 2018 1 commit
  23. 07 Dec, 2018 1 commit
  25. 23 Nov, 2018 1 commit
  27. 10 Oct, 2018 1 commit
  29. 21 Sep, 2018 1 commit
  31. 14 May, 2018 1 commit
  33. 27 Feb, 2018 1 commit
  35. 26 Feb, 2018 1 commit