- 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}
-
- 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
-
-
Seth Brenith authored
This change introduces a new decorator syntax @ifdef which can be used on any class fields in .tq files, and updates SharedFunctionInfo to use it as an example. Bug: v8:7793 Change-Id: I690ae2a10d6cab044eedf5b931e4f95e757ed469 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536985 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61349}
-
- 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}
-
- 04 Apr, 2019 2 commits
-
-
Daniel Clifford authored
Indexed fields in classes can now be initialized using iterators and a spread syntax, e.g.: class Foo { length: Smi; elements[length]: Object; } new Foo{length: 5, elements: ...iter}; where iter implements Torque's iterator protocol. This protocol requires the definition of a method with the following signature: Next(): <type> labels NoMore; Where <type> is the Torque type of the values to be iterated. In the case of indexed field initialization, the type must be the field's type or a subtype thereof. Field initialization with spread is desugared into a loop that calls the spread iterator's Next method and assigns each returned value in order to the corresponding indexed field element. The general machinery for the spread syntax has been added to the ast and parser, however, it can currently only be used in the specific context of indexed field initialization. Spread operators used in any other context will cause an error. Bug: v8:7793 Change-Id: If071e61db8166573c28d13318879c88ba96f6d98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550407 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60639}
-
Tobias Tebbi authored
This changes the syntax for constructing structs and classes to explicitly mention the fieldnames, similar to JavaScript object literals. The fields still have to be listed in the same order as in the struct/class declaration. As in Javascript, {foo: foo} can be abbreviated as {foo}. Example: macro NewJSArray(implicit context: Context)( map: Map, elements: FixedArrayBase): JSArray { return new JSArray{ map, properties_or_hash: kEmptyFixedArray, elements, length: elements.length }; } Drive-by cleanup: Make struct and class constructors follow the same pattern in the parser and the AST. Bug: v8:9018 v8:7793 Change-Id: I22ff7f68270e4f406aa80731a709d41ea52f52bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1551999Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60622}
-
- 03 Apr, 2019 1 commit
-
-
Daniel Clifford authored
Const-qualified fields are allowed in both classes and structs. In both cases, const fields can only be set via initialization during construction. Drive-by: unitialized -> uninitialized Bug: v8:7793 Change-Id: Idec08df30f7897c756b7dd6f2b10bb6012fefb6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547853 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60592}
-
- 27 Feb, 2019 2 commits
-
-
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}
-
Mike Stanton authored
Change-Id: I5f0d915351c24b9a2916b8ab1d4bafb4d7eb21c7 Reviewed-on: https://chromium-review.googlesource.com/c/1491217Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59889}
-
- 15 Feb, 2019 1 commit
-
-
Tobias Tebbi authored
This changes the behavior of overload resolution to not consider if the call happens in a branching context (i.e., with implicit True and False labels from a conditional operator or statement). That way, it is not possible to get different behavior accidentially by using an operator in the wrong context. Instead, there will be a compile error because the call happened in a non-branching context, or because it is ambiguous without this information. The test doesn't perfectly fit the issue (impossible until we have negative tests), but instead tests that equality on HeapNumber's works in boolean contexts, which is something Peter fixed already in https://crrev.com/c/1432596. Bug: v8:8737 v8:7793 Change-Id: I08a3801891587aac705dc93b1c65b0c6cf164107 Reviewed-on: https://chromium-review.googlesource.com/c/1456093Reviewed-by: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59625}
-
- 07 Feb, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 v8:8737 Change-Id: I186cb33eb2e84a47fcb0897978bde9c6dffb9df3 Reviewed-on: https://chromium-review.googlesource.com/c/1456044 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59431}
-
- 06 Feb, 2019 2 commits
-
-
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}
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I6e1fb19fb260350daca8351321a79d038b5fdbd3 Reviewed-on: https://chromium-review.googlesource.com/c/1436053Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59401}
-
- 05 Feb, 2019 1 commit
-
-
Daniel Clifford authored
Bug: v8:7793 Change-Id: Iaf3941b76e261308f656fb92b3c53e6cab5ad350 Reviewed-on: https://chromium-review.googlesource.com/c/1454476 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59356}
-
- 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}
-
- 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}
-
- 17 Jan, 2019 2 commits
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Ifb3f27c7da02c2040fdf5042dafa13b336007f94 Reviewed-on: https://chromium-review.googlesource.com/c/1413875 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58890}
-
Tobias Tebbi authored
This inlines macros with structs as label parameters, to work-around a limitation in the C++ lowering of macros that doesn't allow this. Bug: v8:7793 Change-Id: Idd177c115f3a0b277e8cf99b8a051e6d253359b3 Reviewed-on: https://chromium-review.googlesource.com/c/1417613 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#58888}
-
- 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}
-
- 17 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This changes Torque's builtin pointers to use a Smi representation underneath instead of storing the Code target object. Callsites look up the target entry point through IsolateData::builtin_entry_table. The notable effect of this CL is that builtin pointer calls no longer call any on-heap Code. Bug: v8:7777 Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63 Reviewed-on: https://chromium-review.googlesource.com/c/1379880 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58286}
-
- 14 Dec, 2018 1 commit
-
-
Daniel Clifford authored
In the process, add the bint type (which stands for Best-INTeger), which implements Torque's idea of CSA's ParameterMode. It maps to a different type on 32-bit (Smi) and 64-bit (intptr). There are convert operators that are either no-ops or conversions to-and-from Smi and intptrs on the each platform, depending on the underlying type for bint. This allows Torque code to git most of the benefits of ParameterMode without having to explicitly pass around the mode, since it is almost always OptimalMode anyways. Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162 Reviewed-on: https://chromium-review.googlesource.com/c/1361160 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58253}
-
- 07 Dec, 2018 1 commit
-
-
Daniel Clifford authored
Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58106}
-
- 27 Nov, 2018 1 commit
-
-
Daniel Clifford authored
Change-Id: I57e21c5bc754ca07f52032f85ec8aeff96448dd0 Reviewed-on: https://chromium-review.googlesource.com/c/1342929 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57855}
-
- 19 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I4ce0008f56976102bad952ef2389f40845dcc15b Reviewed-on: https://chromium-review.googlesource.com/c/1340255Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57605}
-
- 14 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
This allows to call generic callables without mentioning all type parameters, if they can be deduced from the types passed as arguments. Bug: v8:7793 Change-Id: Idb37bb6b93c48bd6344c5be19da4e5b19d29593f Reviewed-on: https://chromium-review.googlesource.com/c/1335936Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57515}
-
- 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}
-
- 09 Nov, 2018 1 commit
-
-
Daniel Clifford authored
It sould take an exception argument to ensure the proper re-throw semantics. Change-Id: I36caba1a80c0d3f59c18dce5a58a0c1f0100657d Reviewed-on: https://chromium-review.googlesource.com/c/1328803 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57401}
-
- 05 Nov, 2018 2 commits
-
-
Tobias Tebbi authored
This introduces a new syntax for identifiers and calls: modulename::foo. Such a name is resolved by trying to find a module modulename in one of the parent scopes and looking for foo there. So this roughly corresponds to C++ qualified namespace lookup. Bug: v8:7793 Change-Id: Iedc43e6ebe125cd74575cbbcbf990bbcc0155a1f Reviewed-on: https://chromium-review.googlesource.com/c/1309818 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57238}
-
Tobias Tebbi authored
- Name lookup in module scopes has namespace semantics now: All overloads from all parent modules are combined before overload resolution. - Allow overloads of different callables: runtime-functions, macros, builtins, and generics. - The duplication between the DeclarationVisitor and the ImplementationVisitor is removed: The DeclarationVisitor creates declarables for everything except for implicit generic specializations. The ImplementationVisitor iterates over declarables. The DeclarationVisitor only looks at the header of declarations, not at the body. - Modules become Declarable's, which will enable them to be nested. - Modules replace the existing Scope chain mechanism, which will make it easier to inline macros. - The DeclarationVisitor and Declarations become stateless. All state is moved to contextual variables and the GlobalContext. - Implicit specializations are created directly from the ImplementationVisitor. This will enable template parameter inference. - As a consequence, the list of all builtins is only available after the ImplementationVisitor has run. Thus GenerateBuiltinDefinitions has to move to the ImplementationVisitor. Also, this makes it necessary to resolve the link from function pointer types to example builtins only at this point. Bug: v8:7793 Change-Id: I61cef2fd3e954ab148c252974344a6e38ee2d01d Reviewed-on: https://chromium-review.googlesource.com/c/1304294 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57231}
-
- 31 Oct, 2018 4 commits
-
-
Daniel Clifford authored
This is preparation to support the Torque port of Object.fromEntries, including tests to make sure that the interface of the iterator functions is correct and compiles when used. Change-Id: I2a30ef80a80f42d4744a92746c8cd383abc10c19 Reviewed-on: https://chromium-review.googlesource.com/c/1303726 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57192}
-
Daniel Clifford authored
This is a reland of 0f15ed05 Original change's description: > [torque]: Implement catch handlers for try blocks > > In addition (and in combination), try statements now support "catch" > clauses at the end that catch JavaScript exceptions throw by any builtin > or runtime function contained in the try block: > > try { > ThrowTypeError(context, ...); > } > catch (e) { > // e has type Object > } > > Bug: v8:7793 > Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19 > Reviewed-on: https://chromium-review.googlesource.com/c/1302055 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57169} Bug: v8:7793 Change-Id: I3c4182303acfdfa625654976bec372cf531d954f Reviewed-on: https://chromium-review.googlesource.com/c/1310295Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57184}
-
Maya Lekova authored
This reverts commit 0f15ed05. Reason for revert: Braking Node.js integration, see https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20node.js%20integration/3917 Original change's description: > [torque]: Implement catch handlers for try blocks > > In addition (and in combination), try statements now support "catch" > clauses at the end that catch JavaScript exceptions throw by any builtin > or runtime function contained in the try block: > > try { > ThrowTypeError(context, ...); > } > catch (e) { > // e has type Object > } > > Bug: v8:7793 > Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19 > Reviewed-on: https://chromium-review.googlesource.com/c/1302055 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57169} TBR=danno@chromium.org,mstarzinger@chromium.org,tebbi@chromium.org Change-Id: Ib9e3155ef46cc46851c4ca8a2624fd7634238e13 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/1310197Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57177}
-
Daniel Clifford authored
In addition (and in combination), try statements now support "catch" clauses at the end that catch JavaScript exceptions throw by any builtin or runtime function contained in the try block: try { ThrowTypeError(context, ...); } catch (e) { // e has type Object } Bug: v8:7793 Change-Id: Ie285ff888c49c112276240f7360f70c8b540ed19 Reviewed-on: https://chromium-review.googlesource.com/c/1302055 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57169}
-
- 24 Oct, 2018 1 commit
-
-
Tobias Tebbi authored
This was fixed when introducing the IR. Bug: v8:8216 Change-Id: Iebb212a2c21499b1738832457b660038e3a48975 Reviewed-on: https://chromium-review.googlesource.com/c/1297313Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56931}
-
- 08 Oct, 2018 1 commit
-
-
Daniel Clifford authored
In the process: - Convert TryLabelStatements into TryLabelExpressions - Change TryLabelExpressions to support only single label blocks and de-sugar try/labels into nested try/label statements. This allows the code in a label block to goto subsequent labels in the same try/label statement. - Make otherwise expressions either take IdentifierExpressions which get converted into simple label names OR atomarStatements, which make useful non-label operations, like 'break' and 'continue', useful together with otherwise. Non-label otherwise statements get de-sugared into try/label blocks. Bug: v8:7793 Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db Reviewed-on: https://chromium-review.googlesource.com/c/1266997 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56447}
-
- 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}
-
- 24 Sep, 2018 1 commit
-
-
Daniel Clifford authored
Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
-