- 29 Sep, 2021 1 commit
-
-
Seth Brenith authored
Nobody uses the generated *_FIELDS macros anymore, so we can remove them. I also renamed the generated file to represent its content better. Bug: v8:7793 Change-Id: I49ab39e363d6961e7210cd67018b6fb83b65a162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192191Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77151}
-
- 27 Sep, 2021 1 commit
-
-
Nico Hartmann authored
Prepare the Torque compiler to generate Kythe artifacts to be consumed by CodeSearch. Drive-by changes. * Extend SourcePosition by an offset in the input string, as this is required by the Kythe graph. * Correctly set missing identifier positions in Declarations. Bug: v8:12261 Change-Id: Ida0a4a562c99f58ab924ddde36f3146f3d3fd415 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3181102 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77099}
-
- 11 Mar, 2021 1 commit
-
-
Seth Brenith authored
While working on the Torque compiler, I've sometimes found it difficult to understand Torque's intermediate representation and how it corresponds to the output. In this change, I propose adding a build flag that instructs Torque to emit comments describing its IR, interspersed in the generated code. This is particularly useful for seeing the stack management instructions (Peek, Poke, and DeleteRange) which don't emit any corresponding C++ code. Bug: v8:7793 Change-Id: I24bdec47da76c9bd751b928d3cd92aa513dc6593 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748040Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73352}
-
- 19 Jan, 2021 1 commit
-
-
Z Nguyen-Huu authored
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI Modify that C++ backend so that it can emit either runtime C++ or postmortem debugging code. When in postmortem debugging mode, the overall code structure would look similar with some difference: 1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor. 2. Instead of runtime class names like String, we use uintptr_t 3. When loading data from objects, instead of TaggedField<T>::load or Object::ReadField (which read from the current process), we use the MemoryAccessor and read data from the debuggee process. 4. Return values should be wrapped in the Value struct. Implement the debug accessors for complex length expressions and add test for such class (SmallOrderedHashSet). Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72148}
-
- 08 Dec, 2020 1 commit
-
-
Seth Brenith authored
Currently, all runtime C++ code generated for Torque macros all goes into a single .cc file and corresponding header. This is simple, but limits how we can use that generated code. For example, field accessors are generally expected to be inlinable at compilation time (not relying on LTO). This change updates the Torque compiler to output runtime C++ code into the same *-tq-inl.inc files that contain implementations of member functions for generated classes. All Torque macros transitively called from the top-level macros are included in the same file, to avoid any need for these generated files to #include each other. These macros are emitted within per-file namespaces to avoid multiple-definition build failures. Bug: v8:7793 Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71664}
-
- 28 Oct, 2020 1 commit
-
-
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: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 05 Oct, 2020 1 commit
-
-
Seth Brenith authored
This change adds a new code generator, which supports a subset of the instructions supported by the existing CSAGenerator, and instead of generating CSA it generates runtime C++ code. The new generator is used to generate a set of Torque macros that return slices to indexed fields. These new macros should be sufficient to eventually support Torque-generated field accessors, BodyDescriptors, verifier functions, and postmortem field inspection in debug_helper. Bug: v8:7793 Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70313}
-
- 27 May, 2020 1 commit
-
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . It allows scoped lookups to not crash during CompileCurrentAst, fixes the formatting in an error message, and includes an extra line for convenience when generating macros for bitfields. Change-Id: I7ed9f7d76b3ce5e2cc0f2580d7ba1953da340ae8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216301Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68018}
-
- 26 May, 2020 1 commit
-
-
Seth Brenith authored
This reverts commit 4e5fabae. Reason for revert: performance regressions chromium:1085305, chromium:1084978 Original change's description: > [torque][cleanup] Use more precise field types in a few classes > > This change updates some Torque-defined classes to include more precise > field types where possible. It also updates those classes to use > @generateCppClass. One field was removed because it's unused > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo > actually became less precise because they're based on Script::name, > which is an embedder-provided untyped Local<Value>. (Automatically > generated accessors pointed out this bug easily.) > > This change also includes a couple of minor fixes in Torque. > > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67907} TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67972}
-
- 19 May, 2020 1 commit
-
-
Seth Brenith authored
This change updates some Torque-defined classes to include more precise field types where possible. It also updates those classes to use @generateCppClass. One field was removed because it's unused (PrototypeInfo::validity_cell), and two fields in StackFrameInfo actually became less precise because they're based on Script::name, which is an embedder-provided untyped Local<Value>. (Automatically generated accessors pointed out this bug easily.) This change also includes a couple of minor fixes in Torque. Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67907}
-
- 04 May, 2020 1 commit
-
-
Tobias Tebbi authored
Summary of changes: - GC visitors no longer rely on superclass visitors, but instead visit everything themselves. This enables generating better code. - Try to match simple body descriptors to reduce the amount of generated code. - Turn SizeFor(instance) into an AllocatedSize() method. - Remove the special handling of resizable object sizes from Torque and instead overwrite AllocatedSize in classes that need special handling in C++. - Split the visitor id lists depending on whether the class has pointer fields. - Turn Torque-generated body descriptors into an .inc file to simplify includes. - Fix generated size functions to properly align the size. - Generate GC visitors (and C++ class definitions) for all string classes and FixedArray, WeakFixedArray, and WeakArrayList. - Store generated instance types in Torque class types. This is only used to determine if a type has a single instance type in this CL. Bug: v8:7793 Change-Id: I4d362e96b047c305bd6d065247734957b8958c42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67542}
-
- 09 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the process: * Augment C++-generated Torque classes with SizeFor methods to calculate size of instances. * Add a new "@generateBodyDescriptor" annotation that causes Torque to generate C++ BodyDescriptors code that can be used to visit objects compatible with existing V8 mechanisms, e.g. GC * Fully automate C++ macro machinery so that adding non-extern Torque class doesn't require any C++ changes, including ensuring generation of instance types and proper boilerplate for validators and printers. * Make handling of @export a true annotation, allowing the modifier to be used on class declarations. * Add functionality such that classes with the @export annotation are available to be used from C++. Field accessors for exported classes are public and factory methods are generated to create instances of the objects from C++. * Change the Torque compiler such that Non-exported classes implicitly have the @generateBodyDescriptor annotation added and causes both verifiers and printers to be generated. * Switch non-extern Torque classes from using existing Struct-based machinery to being first-class classes that support more existing Torque class features. Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66621}
-
- 23 Dec, 2019 1 commit
-
-
Nico Hartmann authored
Bug: v8:10053 Change-Id: I90e0798ce490dea035cf4ecb934a4b8d98c61bc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977859 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65551}
-
- 06 Dec, 2019 1 commit
-
-
Seth Brenith authored
This change is the first part of adding Torque support for a "bitfield struct", which represents a set of bitfields packed together into an integer value. With this change, Torque can generate the list of BitField template specializations that allow runtime code to use the bitfield values. The flags used in SharedFunctionInfo are converted to Torque to exercise this functionality. Bitfield values are not yet accessible directly from Torque code. Bug: v8:7793 Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65371}
-
- 07 Oct, 2019 1 commit
-
-
Tobias Tebbi authored
For this, all Torque stub-linkage builtins use TFC instead of TFS, with a custom descriptor added to interface-descriptors.h To avoid having complex logic in the generated code, the new class TorqueInterfaceDescriptor contains the logic to create a CallInterfaceDescriptor from a signature consisting of TNode types. As an example and test, this CL ports StringCharAt to Torque. Bug: v8:7793 Change-Id: I8339d2ad6e4f908ebdc3b8d30244e4bcbd974f21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798427Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64148}
-
- 22 Aug, 2019 1 commit
-
-
Simon Zünd authored
Forge (Google3) can only run 64-bit executables. As Torque runs as part of the build process, we need a 32-bit "cross-compile" mode when we target 32-bit architectures. Note that this flag won't be needed in Chromium/V8 land, since we build V8 with the same bit width as the target architecture. This CL adds a new runtime flag to torque "-m32". When enabled, the flag forces 32-bit word sizes for various pointer/word sizes. By default, the host system sizes from {src/commons/globals.h} are used. R=tebbi@chromium.org Bug: v8:9641 Change-Id: I8701eec45e3fb59dc65049b0a679d34589c4127f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763540 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63334}
-
- 31 Jul, 2019 1 commit
-
-
Seth Brenith authored
This is a reland of 517ab73f Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
-
- 24 Jul, 2019 1 commit
-
-
Zhi An Ng authored
This reverts commit 517ab73f. Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538 Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9376 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62899}
-
- 23 Jul, 2019 2 commits
-
-
Seth Brenith authored
This change begins to implement the functionality described in https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# for investigating V8 state in crash dumps. This change adds a new library, v8_debug_helper, for providing platform- agnostic assistance with postmortem debugging. This library can be used by extensions built for debuggers such as WinDbg or lldb. Its public API is described by debug-helper.h; currently the only method it exposes is GetObjectProperties, but we'd like to add more functionality over time. The API surface is restricted to plain C-style structs and pointers, so that it's easy to link from a debugger extension built with a different toolchain. This change also adds a new cctest file to exercise some basic interaction with the new library. The API function GetObjectProperties takes an object pointer (which could be compressed, or weak, or a SMI), and returns a string description of the object and a list of properties the object contains. For now, the list of properties is entirely based on Torque object definitions, but we expect to add custom properties in future updates so that it can be easier to make sense of complex data structures such as dictionaries. GetObjectProperties does several things that are intended to generate somewhat useful results even in cases where memory may be corrupt or unavailable: - The caller may optionally provide a type string which will be used if the memory for the object's Map is inaccessible. - All object pointers are compared against the list of known objects generated by mkgrokdump. The caller may optionally provide the pointers for the first pages of various heap spaces, to avoid spurious matches. If those pointers are not provided, then any matches are prefixed with "maybe" in the resulting description string, such as "maybe UndefinedValue (0x4288000341 <Oddball>)". Bug: v8:9376 Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62882}
-
Georg Schmid authored
This CL introduces generic Torque structs. Generics are grounded early in the Torque compilation pipeline, meaning that every instantiation of a generic struct with concrete types will be turned into a distinct StructType. As an example, consider a Tuple of types T1, T2: struct Tuple<T1: type, T2: type> { const fst: T1; const snd: T2; } which can be manipulated using generic macros, such as macro Swap<T1: type, T2: type>(tuple: Tuple<T1, T2>): Tuple<T2, T1> { return Tuple<T2, T1>{fst: tuple.snd, snd: tuple.fst}; } Currently there is no type inference for struct instantiation sites, so type arguments have to be provided explicitly: const intptrAndSmi = Tuple<intptr, Smi>{fst: 1, snd: 2}; R=sigurds@chromium.org, tebbi@chromium.org Change-Id: I43111561cbe53144db473dc844a478045644ef6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714868 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62878}
-
- 21 Jun, 2019 1 commit
-
-
Sigurd Schneider authored
Rework the implementation of non-external Torque classes to use Struct machinery rather than FixedArray machinery. This allows Torque-only defined 'internal' classes to the automatically generate class verifiers and printers. As part of this change, generate C++ boilerplate accessors for internal Torque classes, since this is a pre-requisite for the verifiers, printers and other Struct-based functionality. Moreover, augment the header-generating functionality in Torque to create separate header files for field offset definitions, internal class C++ definitions and instance types. Bug: v8:7793 Change-Id: I47d5f1570040c2b44d378f23b6cf95d3d132dacc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607645 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62317}
-
- 11 Jun, 2019 3 commits
-
-
Simon Zünd authored
This CL adds lint errors for unused Torque macros. To prevent lots of noisy warnings, the check is rather narrow. Macros declared as "extern" or marked with "@export" are ignored. Also macros starting with "Convert", "Cast" or "FromConstexpr" are not checked. Drive-by: Removing some unused macros. Bug: v8:7793 Change-Id: Ie0d2e445f8882a9b0ebbda45876b342abf341248 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645312 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62092}
-
Simon Zünd authored
This CL creates global-context.cc and moves the GlobalContext constructor impl to this new file. Preparatory refactoring for import syntax. This CL also removes one unused static method from GlobalContext and changes two use-sites where Get() was used together with a static accessor. Drive-by: "Include what you use" for global-context.h Bug: v8:9183 Change-Id: Iafd877d03af9ad65b1c99ebd9743be64192f45c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649790 Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62081}
-
Simon Zünd authored
This CL introduces an 'import' statement. It does not produce any AST node. The AST contextual directly collects what source id imports what other source id. Currently the import map is unused. In the future, import syntax will be used to implement partial compilation. Bug: v8:7793 Change-Id: I5f09e6254d7ca2e7bc1a93d2e2d82e202cafc8ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649357 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62080}
-
- 05 Jun, 2019 1 commit
-
-
Tobias Tebbi authored
TBR: yangguo@chromium.org Bug: v8:7793 Change-Id: Ie680d72a1da23038d3136f82532496eabbd9c363 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632227 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62004}
-
- 27 May, 2019 1 commit
-
-
Tobias Tebbi authored
Instead of generating one CodeStubAssembler-like class per namespace, Torque-generated macros are now free-standing functions not included from CSA code, and explicitly exported macros become part of the new TorqueGeneratedExportedMacrosAssembler, which CodeStubAssembler inherits from, thus making them available to all CSA code. Structs are now defined in a new header csa-types-tq.h as free-standing types with the prefix "TorqueStruct". This is a preparation for generating per Torque-file instead of per namespace. Change-Id: I60fadc493a63f85d1d340768ec6f11ae47be0cb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628787 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61865}
-
- 21 May, 2019 1 commit
-
-
Simon Zünd authored
This CL changes the existing TorqueError struct into a more general TorqueMessage by adding a "kind" enum. The contextual for lint errors is removed and replaced by a list of TorqueMessages. A MessageBuilder is introduced to help with the different combinations of present information and method of reporting. A lint error with custom SourcePosition can be reported like this: Lint("naming convention error").Position(<src_pos_var>); While a fatal error, with CurrentSourcePosition can be thrown like this: Error("something went horrible wrong").Throw(); This approach is both backwards compatible and should prove flexible enough to add more information to messages or add other message kinds. Bug: v8:7793 Change-Id: Ib04fa188e34b3e8e9a6526a086f80da8f690a6f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617245 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61696}
-
- 17 May, 2019 1 commit
-
-
Simon Zünd authored
The language server and unit tests pass in an empty output directory to signal that no C++ files should be generated. As these generation steps include some validations, they should also be included in language server and unit test compilation runs. This CL introduces a "dry run" flag on the ImplementationVisitor. Additionaly, the implementation visitor wraps the file writing functionality. In case of a dry-run, file writing becomes a no-op. R=sigurds@chromium.org Bug: v8:7793 Change-Id: Id699fdf0b35311ddd3c1f5419baa0237b40ddce4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617244Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61599}
-
- 16 May, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7793 Change-Id: I390b4b5e1f486c53c122f7ebf8dd4106c9bbd10e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607650 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61564}
-
- 15 May, 2019 1 commit
-
-
Simon Zünd authored
This CL adds support for all kinds of Types to "textDocument/symbol" requests. While LSP has support for classes and structs, it does not have support for generic types. Only classes are marked as such, while all other types are marked as structs in terms of the LSP. Special care has to be taken with TypeAliases. Generic call sites introduce a new scope (similar to namespace scopes), where new TypeAliases are created for Generic type arguments. These TypeAliases then point to the specialized type inside this call-site specific scope. To omit the specialized TypeAliaes from the symbols list, they are marked using the "is_user_defined" flag. R=sigurds@chromium.org Bug: v8:8880 Change-Id: I576d1c677a5255d54f7774aa053f431608a4cd0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613240 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#61534}
-
- 14 May, 2019 4 commits
-
-
Sigurd Schneider authored
Change-Id: I75a4a2af4bbe9d495d583b13fb6d885d8509c2b8 Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611797 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61491}
-
Sigurd Schneider authored
This CL introduces the new suffix '-tq' for Torque generated files, and replaces the infix 'FromDSL' in type names with a prefix 'TorqueGenerated'. Change-Id: I1e90460cc0c666da6cf5017e8b3cb7c39c6ac668 Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609798 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61490}
-
Tobias Tebbi authored
The missing check that runtime function parameters have to be tagged lead to a bug: https://chromium-review.googlesource.com/c/v8/v8/+/1604071 drive-by-fix: Remove obsolete verbose mode. It hasn't been maintained since the very early Torque versions, and the remaining printf's are rather useless. Bug: v8:7793 Change-Id: I59adf4c6c5d92a8838cdc638afb2ab7a41550b55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609910 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61483}
-
Simon Zünd authored
The language server needs Torque compilation artifacts like declarables for more advanced features. This CL moves the GlobalContext into the LanguageServerData class when Torque compilation finishes, to preserve all the compiler data. Additionally, all declarables are split up by source id. This makes providing all symbols of a file easier. R=tebbi@chromium.org Bug: v8:8880 Change-Id: I424d1ddc04fcd18934f76a736900bc5d08261c07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601132 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61462}
-
- 10 May, 2019 1 commit
-
-
Seth Brenith authored
This change generates functions that verify the things that Torque knows about objects and their fields. We still must implement each verifier function in objects-debug.cc, but we can call into the generated code to verify that field types match their Torque definitions. If no additional verification is required, we can use the macro USE_TORQUE_VERIFIER as a shorthand for a verifier that calls the corresponding generated function. A new annotation @noVerifier can be applied to both class and field definitions, to prevent generating verification code. This allows fully customized verification for complicated cases like JSFunction::prototype_or_initial_map, which might not exist at all, and JSObject::elements, which might be a one pointer filler map. Because Factory::InitializeJSObjectFromMap fills new objects with undefined values, and many verifiers need to deal with partially- initialized objects, the generated verifiers allow undefined values on every class deriving from JSObject. In cases where stricter checks were previously performed, they are kept in objects-debug.cc. Bug: v8:7793 Change-Id: I84034efadca89ba0aceddf92e886ffbfaa4c23fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594042 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61422}
-
- 08 May, 2019 1 commit
-
-
Simon Zünd authored
This is a reland of 2d45ecf0 The reland properly initializes struct fields in unittests. To prevent this in the future, TorqueCompilerOptions uses brace initialization. Original change's description: > [torque] Introduce force_assert_statements compiler option > > "assert(...)" statements are usually only visited and generated in > debug builds. To provide Language Server support for statements inside > asserts, the force_assert_statements option allows to manually > override this behavior and visit assert statements in release builds. > > R=sigurds@chromium.org > > Bug: v8:7793 > Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180 > Auto-Submit: Simon Zünd <szuend@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61295} Bug: v8:7793 Change-Id: I96ef863c8c85ae87a00cbe858655d4a2c9368b41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599599 Auto-Submit: Simon Zünd <szuend@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61315}
-
- 07 May, 2019 4 commits
-
-
Clemens Hammacher authored
This reverts commit 2d45ecf0. Reason for revert: Fails on arm64 msan: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/26567 Original change's description: > [torque] Introduce force_assert_statements compiler option > > "assert(...)" statements are usually only visited and generated in > debug builds. To provide Language Server support for statements inside > asserts, the force_assert_statements option allows to manually > override this behavior and visit assert statements in release builds. > > R=sigurds@chromium.org > > Bug: v8:7793 > Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180 > Auto-Submit: Simon Zünd <szuend@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61295} TBR=sigurds@chromium.org,szuend@chromium.org Change-Id: Ib0f72a756ff1f6c9838d3d7f837a326b1dab3278 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599549Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61296}
-
Simon Zünd authored
"assert(...)" statements are usually only visited and generated in debug builds. To provide Language Server support for statements inside asserts, the force_assert_statements option allows to manually override this behavior and visit assert statements in release builds. R=sigurds@chromium.org Bug: v8:7793 Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180 Auto-Submit: Simon Zünd <szuend@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61295}
-
Sigurd Schneider authored
This allows generic specializations to appear before the generic itself. Bug: v8:7793 Change-Id: I127fb49380a14cdf2a63854117d25fc865a95352 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599178Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61290}
-
Sigurd Schneider authored
Torque semantic analysis is now a four-stage process: 1. The TypeDeclarationVisitor introduces a TypeAlias for every TypeDeclaration* (or derived) in the Torque source, but does not process the TypeDeclaration* itself. 2. All aliases are resolved in a dependency respecting manner. This CL also changes struct member resolution to happen at this point already. Types for classes are created, but their members are not resolved to allow classes to mutually reference each other in their field types. 3. 'value' declarations (macros, etc.) are processed. 4. Members of classes are processed. Bug: v8:7793 Change-Id: I46108555a5cdf30df03c5d4399ec786ee6cc6df4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584319 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61264}
-