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. 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. 15 Nov, 2019 1 commit
  7. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored 
      This is a reland of 658ff200

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored 
      This reverts commit 658ff200.

Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=​yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

TBR=yangguo@chromium.org,clemensh@chromium.org

Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored 
      We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.

Before:
  class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
  using MyBitField = BitField<int, 6, 4, MyEnum>;

This might reduce compilation time by reducing the number of existing
classes.

The old pattern is forbidden now by making {BitField} final.

R=yangguo@chromium.org

Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  9. 23 May, 2019 1 commit
  11. 25 Apr, 2019 1 commit
  13. 12 Mar, 2019 1 commit
  15. 09 Jan, 2019 1 commit
  17. 18 Dec, 2018 1 commit
  19. 14 Dec, 2018 2 commits
  21. 08 Dec, 2018 1 commit
  23. 29 Nov, 2018 1 commit
  25. 26 Nov, 2018 1 commit
  27. 22 Nov, 2018 1 commit
  29. 26 Sep, 2018 1 commit
  31. 19 Sep, 2018 1 commit
  33. 13 Sep, 2018 1 commit
  35. 12 Sep, 2018 1 commit