- 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}
-
- 20 May, 2019 1 commit
-
-
Tobias Tebbi authored
Macros are now inaccessible from CSA except if their declaration is marked with the "export" keyword. The implicit field accessors for class fields are always exported. In this CL, unwarranted access from CSA is prevented by appending a pseudo-random suffix to non-exported names. This is to be replaced by something more principled, namely by not including these macros at all in the headers included from CSA. Bug: v8:7793 Change-Id: I3ffb2e91a616623f81b4b4508e001ad0cf65d2c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615258 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61672}
-
- 16 May, 2019 2 commits
-
-
Seth Brenith authored
This commit attempts to change as little behavior as possible, but it does require reordering the fields within Map to abide by Torque rules specifying that strong and weak fields must be in separate sections. Also includes some Torque compiler updates: - Allow enums (types extending from integral types) as class fields - Rename @ifdef to @if and add @ifnot for inverse checks - Allow void fields in class declarations, which take up no space and emit no accessors Bug: v8:8952 Change-Id: I1de6f34c1b15ed87d718666a05176980a218e97c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1480919 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61588}
-
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}
-
- 14 May, 2019 1 commit
-
-
Sigurd Schneider authored
This annotation indicates that the class itself is not instantiated, and does not have its own instance type: The instance types that logically belong to the class are the instance types of the derived classes. Currently, we need the indication @dirtyInstantiatedAbstractClass for several classes that are used as both, abstract base classes and concrete classes. The prime example is JSObject which is the base for many other classes, and also serves as the class to allocate plain JSObjects. The annotation is purposefully ugly because in the future we should refactor code to make it unnecessary. Another annotation we introduce is @hasSameInstanceTypeAsParent, which indicates another design pattern that currently occurs in the code-base: Some Torque classes have the same instance types as their parent class, but rename some fields, or possibly have a different map. In such cases, the parent class is not abstract and the derived classes can be seen as refinements of this class (that, for example, narrows the type of a field). In the future, Torque should accomodate this pattern better, but at moment we are content with just indicating where it is used. Bug: v8:7793 Change-Id: I1892dcc7325250df75d80308bf3d767d6d43bcc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607761 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61495}
-
- 13 May, 2019 4 commits
-
-
Michael Hablich authored
This reverts commit a0fc5d72. Reason for revert: This now breaks other bot *shrug*. Original change's description: > Revert "[torque] Add ClassFlag(s) enum" > > This reverts commit 5343d789. > > Reason for revert: breaks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1610023 > > Original change's description: > > [torque] Add ClassFlag(s) enum > > > > This removes the need for passing ever more boolean flags > > to the class constructor. > > > > Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f > > Bug: v8:7793 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61444} > > TBR=danno@chromium.org,sigurds@chromium.org,tebbi@chromium.org > > Change-Id: I38566d8f4203f9cf1e759a3e915cafa86460e6e4 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:7793 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609807 > Reviewed-by: Michael Hablich <hablich@chromium.org> > Commit-Queue: Michael Hablich <hablich@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61456} TBR=danno@chromium.org,sigurds@chromium.org,hablich@chromium.org,tebbi@chromium.org Change-Id: I9edb9a95cd30b6f4c9fd7502eb3a1124e3e8d977 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609808Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#61458}
-
Michael Hablich authored
This reverts commit 5343d789. Reason for revert: breaks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1610023 Original change's description: > [torque] Add ClassFlag(s) enum > > This removes the need for passing ever more boolean flags > to the class constructor. > > Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f > Bug: v8:7793 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61444} TBR=danno@chromium.org,sigurds@chromium.org,tebbi@chromium.org Change-Id: I38566d8f4203f9cf1e759a3e915cafa86460e6e4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609807Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#61456}
-
Sigurd Schneider authored
TBR=tebbi@chromium.org Bug: v8:9239 Change-Id: I9634001a4b6a46680175b9dd04075a313788514c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609544Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61452}
-
Sigurd Schneider authored
This removes the need for passing ever more boolean flags to the class constructor. Change-Id: I0271e1b96585252183dcf070eb440ebdaf2a270f Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607760 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#61444}
-
- 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}
-
- 07 May, 2019 1 commit
-
-
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}
-
- 11 Apr, 2019 1 commit
-
-
Tobias Tebbi authored
This adds references to HeapObject fields to Torque. The syntax is based on Rust (which is essentially C pointer syntax). The type &T is a reference to T (which must be a scalar type for now). We can create references from field access expressions, using the addressof(&) operator: &obj.fieldname To read or assign a reference, we use the dereference(*) operator: *someref = *otherref This CL also uses references internally normal class field accesses, but only if there is no overload for field accessor functions. This allows to have overloaded field accessors for a subtype like FastJSArray. However, there is a change in behavior in that an operator ".fieldname" will stop reference creation and will therefore also stop write access to a class field of the same name. That's why this CL had to add a write overload ".length=" for FastJSArray. References desugar to a pair of a tagged HeapObject pointer and an untagged offset into this HeapObject. On the CSA-side, they are represented by the C++ struct struct TorqueReference { TNode<HeapObject> object; TNode<IntPtrT> offset; }; Bug: v8:7793 Change-Id: Ica6468d47847bd68fb6b85f731cf8fbe142fa401 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557151 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60780}
-
- 09 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
The new @generatePrint annotation automatically generates ...Print methods for objects from their Torque class definition. While this is mostly geared towards objects derived from Struct, it works on any Torque class. Bug: v8:7793 Change-Id: Iaa772879d397b95c7853dafdd9f09a85dbde8e35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557152 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60708}
-
- 27 Feb, 2019 1 commit
-
-
Daniel Clifford authored
Constructors have been removed. Initialization syntax with {} for structs and classes is now limited to the initialization expressions for the fields, so "constructors" deviating from that explicit and complete list of field initialization values must be declared as separate macros. Bug: v8:7793 Change-Id: Ibc26e685c0c8a182732df90b1631eae9371309cb Reviewed-on: https://chromium-review.googlesource.com/c/1489080 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59917}
-
- 20 Feb, 2019 1 commit
-
-
Seth Brenith authored
Currently, it is possible to make the Torque compiler emit uncompilable C++ code if a 'generates' clause is missing. Rather than making the developer spelunk through generated code to find out what went wrong, we can catch this error earlier and print a useful message. Bug: v8:7793 Change-Id: I49fabc1d39f398bf322523901941494b8dab0506 Reviewed-on: https://chromium-review.googlesource.com/c/1477964Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59744}
-
- 18 Feb, 2019 1 commit
-
-
Daniel Clifford authored
In the process, cleanup the StoreFixedArray* operators and change most FixedArray element accesses so that they explicitly use the '.objects' and '.floats' fields. Bug: v8:7793 Change-Id: I3e45a9b7536ec76e1413b7e508d79a56b37604ff Reviewed-on: https://chromium-review.googlesource.com/c/1460948 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59649}
-
- 06 Feb, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Ifc2bf26e9d3bc13d4f2455d6d04ce5e2682626db Reviewed-on: https://chromium-review.googlesource.com/c/1454600Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59404}
-
- 04 Feb, 2019 1 commit
-
-
Daniel Clifford authored
In the process add missing base Torque functionality for 8-bit and 16-bit integers and Cast<> operators to make them easy to use. As a poster child, port the field declarations of SharedFunctionInfo to the class definition in base.tq. As a drive by: Add the missing GN dependency on class-definitions-from-dsl.h Bug: v8:7793 Change-Id: I76a41c2e81ffd1cbb90ac7a4ef8d4003ac86e8dc Reviewed-on: https://chromium-review.googlesource.com/c/1445882Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#59321}
-
- 31 Jan, 2019 1 commit
-
-
Simon Zünd authored
R=tebbi@chromium.org Bug: v8:7793, v8:8562 Change-Id: I783a6d76edd20b73b25cc81395ecadbedd346e8b Reviewed-on: https://chromium-review.googlesource.com/c/1447775Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59239}
-
- 22 Jan, 2019 3 commits
-
-
Daniel Clifford authored
This is a reland of d11a0648 Original change's description: > [torque] Implement safe initialization of classes through hidden structs > > Initialization of classes now happens atomically at the end of the > class constructor only once all of the values for the class' fields > have been fully computed. This makes Torque constructors completely > GC safe, e.g. hardened against allocations or exceptions in > constructors. > > As part of this change, make the 'this' parameter for method calls > explicit rather than implicit. > > Drive by: add validation to check for duplicate field declarations > > Bug: v8:7793 > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88 > Reviewed-on: https://chromium-review.googlesource.com/c/1411252 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58979} Bug: v8:7793 Change-Id: Ia8c23a36a661a73b5dc34437efd514a7c13a1ae8 Reviewed-on: https://chromium-review.googlesource.com/c/1426840Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#59005}
-
Daniel Clifford authored
This reverts commit d11a0648. Reason for revert: <INSERT REASONING HERE> Original change's description: > [torque] Implement safe initialization of classes through hidden structs > > Initialization of classes now happens atomically at the end of the > class constructor only once all of the values for the class' fields > have been fully computed. This makes Torque constructors completely > GC safe, e.g. hardened against allocations or exceptions in > constructors. > > As part of this change, make the 'this' parameter for method calls > explicit rather than implicit. > > Drive by: add validation to check for duplicate field declarations > > Bug: v8:7793 > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88 > Reviewed-on: https://chromium-review.googlesource.com/c/1411252 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58979} TBR=danno@chromium.org,tebbi@chromium.org Change-Id: Id6c46c175f53c5a77db1e6ca242586fba34cd02e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/1426121Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#58980}
-
Daniel Clifford authored
Initialization of classes now happens atomically at the end of the class constructor only once all of the values for the class' fields have been fully computed. This makes Torque constructors completely GC safe, e.g. hardened against allocations or exceptions in constructors. As part of this change, make the 'this' parameter for method calls explicit rather than implicit. Drive by: add validation to check for duplicate field declarations Bug: v8:7793 Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88 Reviewed-on: https://chromium-review.googlesource.com/c/1411252 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58979}
-
- 16 Jan, 2019 1 commit
-
-
Daniel Clifford authored
With the changes in this patch, it is now possible to add methods to both Torque's class and struct types. As a special case, "constructor" methods are used to initialize the values of classes and structs when they are constructed. The functionality in this patch includes: - The refactoring of class- and struct-handling code to share field and method declaration code between both. - Addition of the "%Allocate" intrinsic that allocates raw bytes to be allocated from the V8 GC's NewSpace heap as the basis for freshly created, initialized class objects. - An implementation of a CallMethodExpression AST node that enables calling methods and constructors, including special handling of passing through the "this" pointer for method calls on structs by reference. The syntax for struct construction using "{}" remains as before, but now calls the struct's matching constructor rather than implicitly initializing the struct fields with the initialization arguments. A new syntax for allocation classes is introduced: "new ClassName{constructor_param1, constructor_param1, ...}", which de-sugars to an %Allocate call followed by a call to the matching constructor. - class constructors can use the "super" keyword to initialize their super class. - If classes and struct do not have a constructor, Torque creates a default constructor for them based on their field declarations, where each field's initial value is assigned to a same-typed parameter to the the default constructor. The default constructor's parameters are in field-declaration order, and for derived classes, the default constructor automatically uses a "super" initialization call to initialize inherited fields. - Class field declarations now automatically create ".field" and ".field=" operators that create CSA-compatible object accessors. - Addition of a no-argument constructor for JSArrays that creates an empty, PACKED_SMI_ELEMENTS JSArray using the machinery added elsewhere in this patch. Bug: v8:7793 Change-Id: I31ce5f4b444656ab999555d780aeeba605666bfa Reviewed-on: https://chromium-review.googlesource.com/c/1392192 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58860}
-
- 10 Jan, 2019 1 commit
-
-
Daniel Clifford authored
Class declarations support structured heap data that is a subtype of HeapObject. Only fields of Object subtypes (both strong and weak) are currently supported (no scalar fields yet). With this CL, both the field list macro used with the C++ DEFINE_FIELD_OFFSET_CONSTANTS macro (to make field offset constants) as well as the Torque "operator '.field'" macros are generated for the classes declared in Torque. This is a first step to removing the substantial amount of duplication and boilerplate code needed to declare heap object classes. As a proof of concept, and handful of class field definitions, including those for non trivial classes like JSFunction, have been moved to Torque. Bug: v8:7793 Change-Id: I2fa0b53db65fa6f5fe078fb94e1db3418f908753 Reviewed-on: https://chromium-review.googlesource.com/c/1373971 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58704}
-
- 17 Dec, 2018 1 commit
-
-
Jakob Gruber authored
Currently, Torque's builtin pointers store a Code target underneath and callsites generate a kArchCallCodeObject opcode. When embedded builtins are enabled, the call thus first calls the on-heap trampoline, which finally jumps to the target off-heap builtin code. This will no longer be possible in jitless mode, since on-heap code must not be executable. As a step towards changing the way builtin pointers are called (function pointers will hold the builtin index as a Smi, and callsites look up the off-heap target address and jump there), this CL adds a dedicated opcode for builtin pointer calls to the compiler pipeline. The calling mechanism itself is unchanged, changes there will happen in a follow-up. Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'. Bug: v8:7777 Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58281}
-
- 23 Nov, 2018 1 commit
-
-
Daniel Clifford authored
Bug: v8:7793 Change-Id: I2d5154eabd549c0518ca41dae6ef7bd047f3e1ef Reviewed-on: https://chromium-review.googlesource.com/c/1348072Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57772}
-
- 22 Nov, 2018 1 commit
-
-
Daniel Clifford authored
This is a reland of 74a0ad7d Original change's description: > [torque] Implement intrinsics support > > Also add the first intrinsic and usage of it: %RawCast > > Bug: v8:7793 > Change-Id: Id1e3288e8bab6adb510731076a39590e8fd156be > Reviewed-on: https://chromium-review.googlesource.com/c/1344152 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57692} Bug: v8:7793 Change-Id: I315c7d44f265d0f937598e8afb1c28b08d6a23da Reviewed-on: https://chromium-review.googlesource.com/c/1347472Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57715}
-
- 21 Nov, 2018 2 commits
-
-
Daniel Clifford authored
This reverts commit 74a0ad7d. Reason for revert: Presubmit tests fail Original change's description: > [torque] Implement intrinsics support > > Also add the first intrinsic and usage of it: %RawCast > > Bug: v8:7793 > Change-Id: Id1e3288e8bab6adb510731076a39590e8fd156be > Reviewed-on: https://chromium-review.googlesource.com/c/1344152 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57692} TBR=danno@chromium.org,tebbi@chromium.org Change-Id: Ief78187f2edaf80c715dea676cbd40edd747ad21 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/1346500Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57694}
-
Daniel Clifford authored
Also add the first intrinsic and usage of it: %RawCast Bug: v8:7793 Change-Id: Id1e3288e8bab6adb510731076a39590e8fd156be Reviewed-on: https://chromium-review.googlesource.com/c/1344152 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57692}
-
- 20 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
This enables more seamless interop between Torque and CSA: Since CodeStubAssembler can now inherit from the Torque base namespace, macros defined in the base namespace can be used in CodeStubAssembler macros, even without qualification. At the same time, macros in the base namespace can refer to CodeStubAssembler macros. The only new limitation is that types defined in code-stub-assembler.h cannot be referenced in the signature of macros defined in the base namespace, since this would produce a cyclic header dependency. A work-around for this woud be to put such types (like int31 in this CL) into a separate header included by both. I (mis-)used code-assembler.h for that. Another side-effec is that types and enums defined in CodeStubAssembler have to be accessed in a qualified way from Torque. Other assemblers can now inherit from their Torque equivalent, so porting macros into the corresponding Torque namespace doesn't require any change to the existing use-sites. To avoid C++ ambiguities, the Torque-generated assemblers must not define anything also defined in Code(Stub)Assembler. This includes the type aliases for TNode, PLabel, ... My workaround is to qualify everything in the generated C++. As a drive-by fix, I had to change the formatter to avoid a situation where it doesn't compute a fixed point: putting a keyword at the beginning of a line removes the '\s' in front of it, so I replaced that with '\b'. Bug: v8:7793 Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041 Reviewed-on: https://chromium-review.googlesource.com/c/1341955Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
-
- 13 Nov, 2018 1 commit
-
-
Mike Stanton authored
BUG=v8:7793 Change-Id: Ibcf16998ef9a44ae899a2536ccf02af1b7b7193d Reviewed-on: https://chromium-review.googlesource.com/c/1333410 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57469}
-
- 05 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
No longer use inheritance to associate Torque-generated assemblers with corresponding CSA subclasses. Instead, all references to CSA and CSA-derived assemblers are now explicitly qualified, by generating a short-lived assembler instance in-place. As a consequence, Torque files have to mention the assembler external macros live in. The CodeStubAssembler is the default for this and can be omitted. As a drive-by cleanup, also distinguish between names that are emitted in C++ and names that are intended to be read in error messages. This is relevant for generic instantiations, where the generated names are rather unreadably mangled. As a follow-up, it will be easy to allow for qualified access to different modules, thus implementing full namespace semantics for modules. Bug: v8:7793 Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950 Reviewed-on: https://chromium-review.googlesource.com/c/1309636 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57235}
-
- 29 Oct, 2018 1 commit
-
-
Daniel Clifford authored
In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
-
- 15 Oct, 2018 1 commit
-
-
Tobias Tebbi authored
While this is mostly a mechanical change to enable re-visiting macros for inlining, it has a few user-facing effects: - Labels and (variables, parameters, local constants) are handled separately, so they do not shadow each other. - A local variable or constant is not bound in its initializer. This allows code like: const x = 5; { const x = x + 1; } Bug: v8:7793 Change-Id: I968e1f93d92689737362c803342a797d312e95cd Reviewed-on: https://chromium-review.googlesource.com/c/1276628 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56649}
-
- 11 Oct, 2018 1 commit
-
-
Daniel Clifford authored
The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
-
- 04 Oct, 2018 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I5261122faf422987968ee1e405966f878ff910a1 Reviewed-on: https://chromium-review.googlesource.com/c/1245766 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56391}
-
- 06 Sep, 2018 1 commit
-
-
Florian Sattler authored
Bug: v8:8015 Change-Id: I7f63989a897857c2258ec2bee59aed6100bc689e Reviewed-on: https://chromium-review.googlesource.com/1209346Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#55685}
-
- 08 Aug, 2018 1 commit
-
-
Tobias Tebbi authored
This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
-
- 07 Aug, 2018 1 commit
-
-
Tobias Tebbi authored
In the generated CSA, we called overloaded macros while relying on CSA subtyping of TNodes. This doesn't work well with overloads, because for C++ any TNode subtyping is treated as an implicit conversion, which makes these calls ambiguous for C++. As a solution, we insert implicit_cast conversions for arguments according to the type predicted by Torque. This way, a CSA overload is always called with exactly the signature declared in base.tq. This has the additional benefit that it validates the signatures declared in base.tq, which could previously be too permissive. Also, this triggered a bug in structs, where VisitResult's were carrying the wrong type. Bug: v8:7793 TBR: danno@chromium.org Change-Id: I8ed4bfd04793c8a8805a4a3dd5cf2a85c20ce786 Reviewed-on: https://chromium-review.googlesource.com/1165237 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54948}
-
- 20 Jul, 2018 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I208edf856f0283d840358f3c11bab97af0397056 Reviewed-on: https://chromium-review.googlesource.com/1095192Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54574}
-