- 29 Sep, 2021 1 commit
-
-
Seth Brenith authored
I'm trying to remove annotations and make behavior more consistent. For @generatePrint, there are two options: either generate printers for every extern class, or never generate printers for extern classes. This change implements the option of always generating printers. Classes that require custom printing can easily hide the generated printer by using DECL_PRINTER. This causes the generated file gen/torque-generated/objects-printer.cc to grow to 1600 lines, including many functions that are never used, but I think the consistency benefit outweighs a little more compilation time on one file. This change also removes custom printers in cases where the generated printer includes all of the same content. If folks would prefer the option to never generate printers, I'm open to doing that instead. I like the notion that generating more code could reduce the friction of adding new classes and thereby encourage people to define precise types rather than using FixedArrays, but the current implementation of generated printers is limited, and many printers have been customized to show the data that matters the most. Unlike verifiers and body descriptors, there are no correctness or safety concerns with hand-written printers. Some bugs showed up once we start generating printers for everything, and this change fixes them: - Printers incorrectly included ungettable fields like padding - Printers called getters which might be hidden by hand-written classes - The generated getter for Map::instance_type used ReadField<InstanceType>, which is not an arithmetic type since it's an enum One more tiny drive-by fix: added a missing newline in the printers for JSMap and JSSet. Bug: v8:7793 Change-Id: Ib9e9575fbcb57879935ff18bf4db49fe276d2966 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172190Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77152}
-
- 21 Jul, 2021 1 commit
-
-
Seth Brenith authored
Since most Torque-defined extern classes use @generateCppClass, it makes more sense to instead annotate the small number that don't. This is part of the cleanup work that Nico recommended in [1]. Classes that still have to opt out: - Those that can be converted by https://crrev.com/c/3015666 - HeapObject: sort of special since it's the root of the inheritance hierarchy. Generated code would include two declarations that don't compile until HeapObject is defined: bool IsHeapObject_NonInline(HeapObject o); explicit TorqueGeneratedHeapObject( Address ptr, HeapObject::AllowInlineSmiStorage allow_smi); - SmallOrdered*: these classes use templates on the C++ side, which is not currently representable in Torque. - SwissNameDictionary: according to a comment, the Torque generation for this class is incorrect. I haven't investigated further. Drive-by fix: make the Torque formatter keep LF on Windows rather than writing CRLF. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75841}
-
- 11 May, 2020 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#67719}
-
- 11 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
This creates a .tq file in src/objects for each src/objects/*.h file with Torque-defined classes and moves the object definitions and corresponding helpers/macros there. In addition, we create files convert.tq and cast.tq in src/builtins to move the casts and conversions to. Since Torque-generated .cc files end up as .o files in the same directory, there cannot be two .tq files of the same name. Thus it was necessary to rename src/builtins/arguments.tq and src/builtins/string.tq to not clash with the new files in src/objects. This is a mechanical change that only moves code. Design doc: http://doc/1fh4OUMjQMnQdJm3aiAPXQUNdgbQugkRGdJzDh8hmyzk Bug: v8:9861 v8:9810 v8:7793 Change-Id: I9c54cb50f32b9ae0fb41752199515133eb59ea5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910100Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64892}
-
- 01 May, 2019 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:5367, v8:5368 Change-Id: I86f25f9f658e21a05604f3014e6ebf74f1a8a1f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590164Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61139}
-
- 09 Jan, 2019 1 commit
-
-
Joyee Cheung authored
Bug: v8:8354 Change-Id: I20bb169695d7ecca739f14f9a3ddfafed0dcb964 Reviewed-on: https://chromium-review.googlesource.com/c/1393284Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58652}
-
- 08 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Bug: chromium:919710 Change-Id: I5a04e76fbc925a89b0ebe1916637f6ae5d109b24 Reviewed-on: https://chromium-review.googlesource.com/c/1400419Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58637}
-