- 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}
-
- 09 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change updates CachedTemplateObjectMap, BreakPointInfo, and BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3. It also removes Tuple3 because nothing else used Tuple3. By avoiding tuple types, we get various benefits that Torque can provide: - stricter debug verifier functions - accessors, cast functions, and printers are generated - BreakPoint and BreakPointInfo have different instance types, so you can tell them apart at runtime or in a debugger Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65668}
-
- 21 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
This introduces a new keyword "shape" in addition to "class", which allows the definition of a type that extends a JSObject subclass and specifies one or several maps with statically known in-object properties. Differences compared to normal classes: - Shapes are transient since they specify maps instead of instance types. - Shapes have a known size. - Fields of shapes are always in-object properties. In particular, this means that their offset is after kHeaderSize. - It's forbidden to inherited from shapes. - Since shapes usually specify NativeContext-dependent maps, it's not possible to write runtime type-checks for them. Thus this CL avoids mapping them to their own TNode type, as the CAST macro won't work properly. We had runtime-checks for some of them nevertheless, some of them scarily confusing like IsJSSloppyArgumentsObject, that actually just checked the instance type. Drive-by cleanups and simplifications: - Allow subclassing from non-abstract classes and remove @dirtyInstantiatedAbstractClass. This attribute stems from a mis- conception of how instance types work, and with this change it ceases to have semantic influence. - Replace the existing JSArgumentsObject subclasses into two shapes. JSArgumentsObjectWithLength had to be removed since shapes don't support subclassing. - Place kHeaderSize correctly for objects with indexed fields. Design doc: https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU Bug: v8:8944 Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65108}
-
- 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}
-