Skip to content

V
V8
Switch branch/tag
  1. 06 May, 2021 1 commit
  3. 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. 17 Aug, 2020 1 commit
  7. 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
  9. 04 May, 2020 1 commit
  11. 18 Nov, 2019 1 commit
  13. 09 Oct, 2019 1 commit
  15. 01 Oct, 2019 1 commit
  17. 16 Sep, 2019 1 commit
  19. 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
  21. 23 May, 2019 2 commits
  23. 22 May, 2019 1 commit
  25. 29 Apr, 2019 1 commit
  27. 10 Apr, 2019 2 commits
  29. 15 Jan, 2019 1 commit
  31. 09 Jan, 2019 1 commit
  33. 20 Dec, 2018 1 commit
  35. 08 Dec, 2018 1 commit
  37. 27 Nov, 2018 1 commit
  39. 22 Nov, 2018 1 commit
  41. 06 Oct, 2018 1 commit
  43. 04 Oct, 2018 1 commit
  45. 02 Aug, 2018 1 commit
  47. 20 Jul, 2018 1 commit
  49. 18 Jul, 2018 1 commit
  51. 01 Jun, 2018 1 commit
  53. 15 May, 2018 1 commit