- Lower LoadObjectField to LoadFromObject
- Mark LoadFromObject and StoreToObject as non-allocating
- Use optimizable BitcastTaggedSignedToWord in TaggedIsNotSmi check
R=jarin@chromium.org, tebbi@chromium.org
Change-Id: I42992d46597be795aee3702018f7efd93fcc6ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657926
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62173}
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}
This CL adds a lint error for variables that are unnecessarily bound
with 'let' when they could be bound using 'const. This test is skipped
for struct types. For struct types, the "constness" also depends on
the struct methods called and whether these methods write to the struct
or not. This is not straight-forward to detect.
Drive-by: Fix all the newly introduced lint errors.
Bug: v8:7793
Change-Id: I0522ffcc4321350eef2e9573b8430bc78200ddce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645322
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62085}
This CL adds lint errors when 'let' bindings, arguments and labels
are not used. Note that errors for 'const' bindings will be added
later.
In cases where arguments are actually needed to match the signature,
the warning can be silenced by prefixing identifiers with "_". This
might be needed for generic specializations or builtins called from
TurboFan. Trying to use a variable or label that was marked with
"_" results in a compilation error.
Implicit arguments are not linted. They are implemented using exact
string matching. Prefixing an implicit argument with "_" in a callee
would break all callers as the names would no longer match.
Drive-by: Fix all new lint errors in the existing Torque code.
Bug: v8:7793
Change-Id: I68b3c59c76b956e9f88709e9388a40a19546ce52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645092
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@{#62027}
Bug: v8:9247
Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61928}
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}
This is a reland of c33a1ef227
It seems the revert was based on a flake.
Original change's description:
> Reland "[torque] move class tests to unittests"
>
> This is a reland of f589d56101
>
> Now with an ASAN-container-overflow false positive workaround:
> Somehow ASAN was unhappy about a simple
> std::vector<std::string>::push_back.
> Increasing the std::vector capacity before doing the push_back
> strangely fixes the problem.
>
> Original change's description:
> > [torque] move class tests to unittests
> >
> > This avoids the generation of fake external classes.
> >
> > Bug: v8:7793
> > Change-Id: I9744b299d3ec474d72b298b4f6143f95e345d1d9
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1625991
> > Reviewed-by: Simon Zünd <szuend@chromium.org>
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#61778}
>
> TBR: szuend@chromium.org, sigurds@chromium.org
> Bug: v8:7793
> Change-Id: Ifa1958e4d6e850ba27632aa95c7efaf5ca4bfefa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627970
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61807}
Bug: v8:7793
Change-Id: Ia403f1b784500c0903172f13e74c0b325e82599f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627980
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61819}
This is a reland of f589d56101
Now with an ASAN-container-overflow false positive workaround:
Somehow ASAN was unhappy about a simple
std::vector<std::string>::push_back.
Increasing the std::vector capacity before doing the push_back
strangely fixes the problem.
Original change's description:
> [torque] move class tests to unittests
>
> This avoids the generation of fake external classes.
>
> Bug: v8:7793
> Change-Id: I9744b299d3ec474d72b298b4f6143f95e345d1d9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1625991
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61778}
TBR: szuend@chromium.org, sigurds@chromium.org
Bug: v8:7793
Change-Id: Ifa1958e4d6e850ba27632aa95c7efaf5ca4bfefa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627970
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61807}
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}
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}
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}
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}
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}
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}
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}
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}
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/+/1551999
Reviewed-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}
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}
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}
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/1456093
Reviewed-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}
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/1445882
Reviewed-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}
This is a reland of d11a0648af
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/1426840
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59005}
This reverts commit d11a0648af.
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/1426121
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58980}
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}
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}
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}
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}
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}
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}
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/1335936
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57515}
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}
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}
- 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}
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}
This is a reland of 0f15ed05b9
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/1310295
Reviewed-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}
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}
This was fixed when introducing the IR.
Bug: v8:8216
Change-Id: Iebb212a2c21499b1738832457b660038e3a48975
Reviewed-on: https://chromium-review.googlesource.com/c/1297313
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56931}
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}
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}
To make the changes in base.tq work, there were 2 changes needed on
the C++ side:
- calls to "FromConstexpr" are generated by the compiler for
implicit conversions.
- type switch is desugared and uses "Cast"
R=jgruber@chromium.org, tebbi@chromium.org
Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714
Reviewed-on: https://chromium-review.googlesource.com/1219629
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55794}
This CL makes sure, that logical operators (||, &&) always have return
type never. Together with a check that never is never passed as a
function argument, this prevents faulty evaluation as in !(x || y).
Before, the logical operators had a behavior similar to
(bool labels Taken, NotTaken), with a fast exit if the left-hand side
allowed shor-circuit evaluation, but returning the right-hand side
otherwise. Since we want to allow existing (a || b || c) patterns in
the codebase, this requires weakening the restriction that the left-
and right-hand side need to have the same type. Now the possibilites
are:
bool, never
never, bool
never, never
bool, bool
constexpr bool, constexpr bool
Bug: v8:8137
Change-Id: I9576b337dc4008ac58b4625e77fef4e73bcdd6e3
Reviewed-on: https://chromium-review.googlesource.com/1215162
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55750}
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}
Previously, we requested instantiation of generics prior to selecting
a template overload, which resulted in unused templates being
instantiated, possibly triggering unnecessary compile errors.
Bug: v8:7793
Change-Id: I45f4bdbf8aa93749ece416c6c7458d64e6e051f5
Reviewed-on: https://chromium-review.googlesource.com/1154977
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54950}
We currently only expose this to desugarings and not in the grammar
to keep 'const' and 'let' bindings consistent.
A side-effect of this change is that it is now possible to use a
shadowed name in the initializer of a const binding.
Bug: v8:7793
Change-Id: Ic2ca6af0735acf0e748d394f9039fe6612bd4a06
Reviewed-on: https://chromium-review.googlesource.com/1150534
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54755}
This CL changes the for-loop so all parts are optional, allowing
loops like:
for (;;) {}
for (;; ++i) {}
...
R=danno@chromium.org, tebbi@chromium.org
Bug: v8:7793
Change-Id: I7bf9ef9e59d55eb9ae9f38904a1c1106ae50df5a
Reviewed-on: https://chromium-review.googlesource.com/1152727
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54752}
Struct are bundles of value types. They are essentially just shorthand
for passing around a group of individually defined values.
Struct types are declared like this:
struct A {
x: Smi;
y: int32;
}
and can be constructed explicitly like this:
A{0, 0}
Structs can be used wherever other types are used (e.g. variables,
parameters, return values) except for parameter/return types of
builtins and runtime functions.
Struct use field access notation to set/get their values like this:
let a: A = A{0, 0};
let b: Smi = a.x;
a.y = 0;
Change-Id: I9fd36a6514c37882831256a49a50809c5db75b56
Reviewed-on: https://chromium-review.googlesource.com/1122133
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54501}
This CL adds local const bindings. This means that instead of
generating TVARIABLEs for variables, we can generate simple TNodes.
Example:
macro FooBar(): {
const kSomeSmi: Smi = 10;
...
}
This CL also enforces that variables with a constexpr type are bound
using 'const' and not 'let'.
R=tebbi@chromium.org
Bug: v8:7793
Change-Id: Id20a18149df9fc374ce718bdb1478e3eabb6e6df
Reviewed-on: https://chromium-review.googlesource.com/1138316
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54479}
This CL adds constants that can be defined in the module scope:
const kConstexprConst: constexpr int31 = 5;
const kIntptrConst: intptr = 4;
const kSmiConst: Smi = 3;
They are implemented by generating "mini-macros" that return the
expression on the right-hand side of the assignment.
Bug: v8:7793
Change-Id: I0a476cb3111707fad56bf15e9547b377c7adab37
Reviewed-on: https://chromium-review.googlesource.com/1114745
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54430}
Variables/return values with constexpr type cannot have multiple
assignments. We check this now.
For conditionals, it is important to always infer a non-constexpr type.
This CL adds the ability to map any type (including union types) to be
mapped to their non-constexpr variant. Conditionals infer their type as
the non-constexpr version of a combination of the two branch types.
In addition, this improves subtyping for constexpr types:
If A extends B, then constexpr A extends constexpr B.
This makes it necessary to clean up "constexpr String", which has nothing
to do with tagged values.
Bug: v8:7793
Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6
Reviewed-on: https://chromium-review.googlesource.com/1122864
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54167}
This CL adds the newline character as a valid character
in Torque strings.
You can now write Print('Hello, World!\n') in Torque and it works!
Change-Id: I2a1f87cfef492fedd3d24086e226d3ebaf882115
Reviewed-on: https://chromium-review.googlesource.com/1118229
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Théotime Grohens <theotime@google.com>
Cr-Commit-Position: refs/heads/master@{#54089}
This CL adds a fast path for DataView getters and setters when the
load or store to be performed is aligned and when the requested
endianness matches the platform endianness.
In that case, we can just emit the right load/store instruction
instead of having to read and write data byte by byte.
Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0
Reviewed-on: https://chromium-review.googlesource.com/1106168
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54005}
In the process:
- Add strict ordering of Types so that name mangling is consistent
and build time. Previously, the UnionType stored the union's
types in a std::set<const Type*>, which did not have a consistent
ordering of the types in the set.
- Add a int31 type to enable consistency and correctness of
handling of 'constexpr int31' values on the C++ side.
- By removing the "implicit" keyword for operators, there is now
one less difference between operators and calls, another
incremental step in unifying operators and calls.
- Enable external (i.e. C++-defined) generic specializations
- Add CSA support for checking double ElementsKinds, including
tests.
- Clean up some constexpr/non-constexpr handling of ElementsKinds.
Bug: v8:7793
Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8
Reviewed-on: https://chromium-review.googlesource.com/1091155
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53664}
This CL changes the behaviour of number literals. Large integer
literals (bigger than Smi, but fit into int32) should have
type "constexpr int32" instead of "constexpr float64".
R=tebbi@chromium.org
Change-Id: I3a83c617c7d257451d299670c891fac5b21d045c
Reviewed-on: https://chromium-review.googlesource.com/1084991
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53522}
This CL is a proposal to add "checked" casts (CAST in CSA) to the Torque language.
The CL adds the "unsafe_cast<>" operator that emits a "CAST".
Example:
let n: Number = ...;
...
if (TaggedIsSmi(n)) {
let m: Smi = unsafe_cast<Smi>(n);
...
}
The cast wont incur a runtime overhead now.
R=tebbi@chromium.org
Change-Id: I9fca90d1d11e61617ba0270e5022fd66200e2195
Reviewed-on: https://chromium-review.googlesource.com/1070151
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53416}
This CL adds grammar support for function pointers to generic builtins.
It also instantiates generic specializations when they are only used
in an assignment to a function pointer.
Example:
builtin GenericBuiltinTest<T: type>(c: Context, param: T): Object {
return Null;
}
let fnptr: builtin(Context, Smi) => Object = GenericBuiltinTest<Smi>;
Change-Id: Ib7e5f47ffc05f14eb5d0b789936587263dfb961d
Reviewed-on: https://chromium-review.googlesource.com/1068731
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53284}
This CL adds the new type expression
builtin(Context, ArgType1, ...) => ReturnType
and allows to use Torque-defined builtins as values of this type, as well
as calling values of this type.
The new function pointer types are subtypes of Code.
Change-Id: Ib7ba3ce6ef7a8591a4c79230dd189fd25698d5b9
Reviewed-on: https://chromium-review.googlesource.com/1060056
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53217}
This CL changes the generated C++ code for LabeledStatementBlocks to
only emit labels if they are used.
Prior to this CL, when a label was only used on one path of an
if constexpr expression, and not at all anywhere else,
the try/label construct would BIND a label that was not used,
causing a CSA verification error.
R=tebbi@chromium.org
Change-Id: Ia81a0cd081b84528c95bbdbdb98b9ab51928e13f
Reviewed-on: https://chromium-review.googlesource.com/1057247
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#53173}
Change-Id: I37ed9115c099f3d17f23a26348a1bbf5f773ee32
Reviewed-on: https://chromium-review.googlesource.com/1056668
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#53136}
In the process, add a few simple tests for "constexpr" expressions, which
identified a few bugs that are also fixed in this CL.
Change-Id: I97486c781572642d2b574b92133b1f9cda3db592
Reviewed-on: https://chromium-review.googlesource.com/1055493
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53135}
