This change adds a new abstract type Lazy<T> which can be used to
interoperate with CSA code that uses LazyNode. This new type has special
code-generation rules because its generated type is not TNode<...> but
std::function<TNode<...>()>. Torque code can do nothing with this type
except pass it around, but passing it to the CSA function RunLazy is an
easy way to execute the std::function and get back a normal value.
Torque code can also create Lazy<T> values using the intrinsic function
%MakeLazy, which takes the name of a macro as its first parameter,
followed by arguments to that macro which will be passed when the
LazyNode is evaluated. We use the macro's name because the language
doesn't support taking references to macros, and implementing such a
feature would be complicated.
Bug: v8:7793
Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72964}
This uses the old trick from TypedArrays: a Smi-like all zero
pattern plus an offset that actually contains a raw address to access
off-heap data.
Bug: v8:7793
Change-Id: Ia44448d4ff7e2dcaa02a2c5653f622fb93c3dd09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534817
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71287}
This allows templates to preserve the type of implicit parameters to
select a better ovleroad, without generally extending overload
resolution to implicit parameters, which could be confusing.
Bug: v8:7793
Change-Id: Ie57090a295b0b46d03789829b975fc16e2a9c5b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329630
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69177}
If an enum case has a type annotation, the corresponding enum constant
has this type. This is useful for typing context slots.
Bug: v8:7793
Change-Id: I8b91c3bd3686048f98cce3c034eec4e36f925e5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329631
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69165}
e.g. the following is now valid Torque code:
macro TestA(implicit c: Context)() {}
macro TestB(): bool {
return TestA();
}
This is handy for more flexible usage of generics that may or may not
use implicit parameters deep inside their specializations.
Note that this change doesn't change the fundamental rigor (or lack
thereof) around checking the usage of implicit parameters, which
already do not require '_' before their parameter identifier if
unused. It just silences errors in cases where a call site doesn't
implicitly pass a parameter that ultimately doesn't have a use site
and adds meaningful error messages in the case that it does.
Bug: v8:7793
Change-Id: I559d06c0864a7e79fe52bee5a9a7af9941889748
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274127
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68618}
This change enables automatic generation of Cast<> operators for
classes that are defined in Torque.
* Cast<> macros are generated for all classes that are defined in
Torque code that are neither shapes nor marked with a new
@doNotGenerateCast annotation.
* Implicitly generated Cast macros simply call through to an
internally-defined "DownCastForTorqueClass" macro that implements
the cast using one of three strategies for efficiency. If the class
has subclasses (i.e. a range of instance types including subtypes),
the DownCastForTorqueClass checks for inclusion in the instance type
range. If the class has a single instance type (i.e. no subclasses),
then either 1) a map check is used if the class has a globally-
defined map constant or 2) an equality check for the instance type
is used.
* Added new intrinsics to introspect class information, e.g. fetching
instance type ranges for a class, accessing the globally-defined map
for a class.
* Removed a whole pile of existing explicit Cast<> operators that are
no longer needed because of the implicitly generated Cast<> macros.
* Added tests for the new Cast<> implementations.
Bug: v8:7793
Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68478}
When accessing a field of a non-class type, Torque will generate a
CallAccess LocationReference, which has an unknown type. We still tried
to access it's type, resulting in a DCHECK failure.
Bug: v8:7793
Change-Id: I3650643e29db852783eca1e166b700eebd1b8dc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209056
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68180}
We can do a good job of optimizing Torque expressions that load and
check multiple bitfields from a bitfield struct, but only if those
expressions are written using the binary `&` operator as opposed to the
logical `&&`. This change adds a lint rule to detect some simple cases
where we should clearly prefer `&` to `&&`.
Bug: v8:7793
Change-Id: Id996a7971cff8f7f83198075a172170d9c7d42e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207666
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67991}
Marja pointed out that the following code causes a Torque crash:
Convert<Smi>(MessageTemplate::kFoo)
This change is a small fix to not crash in that case.
Bug: v8:7793, v8:10475
Change-Id: I7856366856a4cd7facdb19686a2d4c92b0d04516
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182175
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67580}
Torque desugars try-catch/label constructs with several handlers
into nested try structures, with the first handler ending-up
innermost. So currently, if you write
try {
...
} label Foo {
Throw(...);
} catch (e) {
}
The catch will catch the preceding Throw in another handler.
This is different from how multiple try-catch handlers are done in
languages like Java, where throwing from a preceding catch handler
is not caught by a later one. To avoid this possible ambiguity, this
CL prohibits this pattern, enforcing that a catch handler comes first,
before any other label-handler attached to the same try.
This way, a catch handler never catches from any other handler on the
same try, since they have to come later.
Bug: v8:7793
Change-Id: I943f14b2393d307c4254a3fc3a78f236dbcf86df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169098
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67516}
- Allow type expression for abstract type supertypes.
For consistency, and ease of implementation, also allow this for enums.
- Allow subtyping of structs. This requires changing all places where we
checked for struct types and instead check if we have a subtype of a
struct type.
- This allows defining two subtypes of the Reference<T> struct for
mutable and constant references. Mutable references are a subtype of
constant references.
- &T desugars to MutableReference<T>
const &T desugars to ConstReference<T>
- A const field of a class produces a constant reference.
A const field of a mutable reference to a struct is const.
A mutable field of a const reference to a struct is const.
- It is possible to assign a new struct value to a mutable reference to
a struct, even if the struct contains const fields. This is analogous
to allowing assignments of let-bound structs with constant fields.
Not in this CL:
- A notion of const slices.
- Applying const to appropriate class fields.
Bug: v8:7793
Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66759}
This reverts commit 4dc1fb4e04.
Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea962e.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> > is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> > occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> > code for IncBlockCounter match with what was generated before this
> > change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> > API. The format matches existing bitfields but with an offset value
> > that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}
This reverts commit e5e4ea962e.
Reason for revert: mysterious performance regression chromium:1052756
Original change's description:
> [torque] Support bitfield structs stored within Smis
>
> This change moves the definition of the bits stored in DebugInfo::flags
> to Torque, and updates the only Torque usage of that field to use more
> natural syntax. This is intended as an example of common patterns found
> in various other classes. Several supporting changes are required:
>
> 1. Add a new type representing a bitfield struct stored within a Smi. It
> is currently called SmiTagged, but I'm open to suggestions.
> 2. Add an enum-style output for Torque bitfield structs whose bitfields
> occupy only one bit each.
> 3. Add a new case to MachineOperatorReducer that makes the generated
> code for IncBlockCounter match with what was generated before this
> change.
> 4. Add support for reporting these bitfields in the postmortem debugging
> API. The format matches existing bitfields but with an offset value
> that includes the SMI shift size.
>
> Bug: v8:7793
> Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66182}
Bug: chromium:1052756, v8:7793
Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66349}
This change moves the definition of the bits stored in DebugInfo::flags
to Torque, and updates the only Torque usage of that field to use more
natural syntax. This is intended as an example of common patterns found
in various other classes. Several supporting changes are required:
1. Add a new type representing a bitfield struct stored within a Smi. It
is currently called SmiTagged, but I'm open to suggestions.
2. Add an enum-style output for Torque bitfield structs whose bitfields
occupy only one bit each.
3. Add a new case to MachineOperatorReducer that makes the generated
code for IncBlockCounter match with what was generated before this
change.
4. Add support for reporting these bitfields in the postmortem debugging
API. The format matches existing bitfields but with an offset value
that includes the SMI shift size.
Bug: v8:7793
Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66182}
This allows the definition of classes with several arrays and ports
SmallOrderedHashTable subclasses to Torque as an example, including
the existing CSA allocation functions for them.
Overview of changes:
- Introduce ResidueClass to encapsulate the modulo-arithmetic
necessary to do alignment checks.
- Add MachineOperatorReducer to the CSA pipeline to address now
missing CSA ad-hoc constant folding that got blocked by a
temporary phi.
- Allow assignments to references to structs. This is needed to
initialize the data_table part of SmallOrderedHashMap.
- Make the NumberLiteralExpression AST-node store a double instead
of a string. This is necessary to detect arrays with constant size
used for padding.
- Turn offsets into base::Optional<size_t> to ensure we don't use
an invalid or statically unknown offset.
- Remove CreateFieldReferenceInstruction since it doesn't work for
complex offset computations and the logic can be expressed better
in ImplementationVisitor.
- Validate alignment of structs embedded in classes.
Bug: v8:10004 v8:7793
Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65538}
This CL implements enums in Torque in three steps:
1.) It implements necessary changes to Torque's type system. In
particular, the constraints on constexpr types are relaxed such that
constexpr types can exist without a corresponding non-constexpr
version. Furthermore, constexpr and their non-constexpr counterpart
need not be of the same kind of type. This allows an AbstractType to
have a UnionType as its non-constexpr counterpart.
2.) The enum feature itself is realized as a pure desugaring in the
parser, where all required types, constants and macro specializations
(like FromConstexpr<>) are generated from a simple enum declaration,
such that enum entries are not just constants, but are namespace
scoped and have distinct types so that they can be used within
typeswitch constructs.
3.) Almost all of the existing constants defined in torque
(.tq files) are ported to new enum definitions.
Bug: v8:10053
Change-Id: I72426d3b1434f301fd690847e15603de0dc1021b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964392
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65503}
This makes it obvious that methods are actually macros.
Also, in the future, we might allow methods that are actually builtins.
Bug: v8:7793
Change-Id: Ib641c4b5a222b27c67aa0c31fd3611ed4a11842c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967330
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65455}
This CL generalizes and improves how we handle allocations in Torque.
Overview of the changes:
- Remove obsolete special handling for JSObject classes, since it was
incomplete: It breaks as soon as slack tracking is active.
- Handle array initialization using slices.
- Properly align allocation sizes. This enabled allocating strings.
- Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
now than the old CSA code since allocation size alignment and
large-object space allocation just happen out-of-the-box.
- Remove obsolete or unnecessary intrinsics, some of them turn into
macros in the torque_internal namespace.
- Distinguish between header size and overall size for ClassType,
make size optional and only defined when it is statically known.
Bug: v8:10004 v8:7793
Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65397}
This CL attempts to run unittests on Fuchsia
using Infra
Bug: chromium:934932
Change-Id: I4b7cb740e17e65e91ca8c6ba6dfd07719e473e20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948709
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65349}
Currently it's pretty easy to write Torque code that generates an error
in some common generic function such as Convert<To: type, From: type>,
and unless your change is very small, it can be hard to figure out what
part of it caused that macro specialization. This CL updates the Torque
compiler to emit some extra information about the stack of code
positions that caused a specialization of a macro or builtin, similar to
what Clang does for C++ templates. Obviously there might be multiple
places that require a particular specialization, but we only report the
first one that caused the specialization to be created.
Bug: v8:7793
Change-Id: I4c0fbf1fd437d0eb0d7d5002baef7a5361aea5ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1911019
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64987}
Now that we can represent specific weak types with Weak<T>, this CL
updates the generated verifier functions so that they permit weak
references only to the specified type. As an example, consider the
verifier emitted for the following field in PrototypeInfo:
object_create_map: Weak<Map>|Undefined;
We used to emit the following, which allowed any weak reference:
CHECK(object_create_map__value.IsWeakOrCleared()
|| object_create_map__value.GetHeapObjectOrSmi().IsOddball());
With this change, we emit a stricter check:
CHECK(object_create_map__value.IsCleared()
|| (!object_create_map__value.IsWeak()
&& object_create_map__value.GetHeapObjectOrSmi().IsOddball())
|| (object_create_map__value.IsWeak()
&& object_create_map__value.GetHeapObjectOrSmi().IsMap()));
Bug: v8:7793
Change-Id: I4be236d97dedbcdd6c98207928aee8bda2a77f00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914613
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64965}
Overview:
- Change basic type hierarchy to split Tagged into StrongTagged (= Object) and
and WeakHeapObject. This enables to emit the right CSA types (Object, MaybeObject).
- The new Weak<T> type encodes a possibly cleared weak bit pattern that
points to type T if it's not cleared.
- Make TNode<Object> a subtype of TNode<MaybeObject> so that the generated code
compiles on the C++ side. Drive-by change: simplify a few CSA helpers by using
MaybeObject as a common supertype of MaybeObject and Object.
- Port CreateObjectWithoutProperties and LoadMapPrototypeInfo.
Bug: v8:7793
Change-Id: I895a6501ce3e287ea8cf4065aaff3a5535245ab4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889870
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64876}
This expands the existing mechanism for generic structs to also cover
abstract types. This involves:
- Moving the SpecializationKey from StructType to Type, so that it's
also available to AbstractType.
- Moving the generic parameters out of the StructDeclaration AST node
and using the existing GenericDeclaration AST node for generic structs
and abstract types too.
- The GenericStructType declarable gets generalized to GenericType.
This will be useful for defining a Weak<T> type for weak pointers.
Bug: v8:7793
Change-Id: I183b3a038a143cf0ae5888150104c4a025fd736c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859623
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64533}
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them.
R=tebbi@chromium.org
Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62939}
For every @noVerifier in base.tq, this change either removes it or
ensures that it has some annotation explaining why it can't be removed.
The @noVerifier usages that can't be removed fall into the following
categories:
1. Classes that don't have their own instance types and therefore have
no meaningful way to do an Is...() check
2. Fields that might not exist
3. Fields that are waiting for MaybeObject support in Torque
Bug: v8:9311
Change-Id: Id452d4151ec07347ae96a9b5f3b26e2ac8065d31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659134
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62263}
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 introduces an 'import' statement. It does not produce any AST
node. The AST contextual directly collects what source id imports what other
source id.
Currently the import map is unused. In the future, import syntax will be
used to implement partial compilation.
Bug: v8:7793
Change-Id: I5f09e6254d7ca2e7bc1a93d2e2d82e202cafc8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649357
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62080}
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}
This CL fixes a crash when "constexpr" is infered from the intializer
expression of a variable declaration.
R=sigurds@chromium.org
Bug: v8:7793
Change-Id: I0ec51280fa145d874424e885905bbf79c93b3904
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627983
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61826}
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}
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}
The missing check that runtime function parameters have to be tagged
lead to a bug: https://chromium-review.googlesource.com/c/v8/v8/+/1604071
drive-by-fix: Remove obsolete verbose mode. It hasn't been maintained
since the very early Torque versions, and the remaining printf's are
rather useless.
Bug: v8:7793
Change-Id: I59adf4c6c5d92a8838cdc638afb2ab7a41550b55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609910
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61483}
This is a reland of 2d45ecf09f
The reland properly initializes struct fields in unittests. To prevent
this in the future, TorqueCompilerOptions uses brace initialization.
Original change's description:
> [torque] Introduce force_assert_statements compiler option
>
> "assert(...)" statements are usually only visited and generated in
> debug builds. To provide Language Server support for statements inside
> asserts, the force_assert_statements option allows to manually
> override this behavior and visit assert statements in release builds.
>
> R=sigurds@chromium.org
>
> Bug: v8:7793
> Change-Id: I38f48e35f2b0a1a98abb74b7babb1edd2d7dba24
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599180
> Auto-Submit: Simon Zünd <szuend@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61295}
Bug: v8:7793
Change-Id: I96ef863c8c85ae87a00cbe858655d4a2c9368b41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599599
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61315}
This CL changes lint errors to not be printed directly to stderr.
Instead, they are collected in a list that gets surfaced via
the TorqueCompilerResult. This is done so they can be presented
to language server clients.
This change also removes the "abort_on_lint_errors" option.
API users can now decide for themselves what to do, depending on
the presence of lint errors in the returned list.
R=sigurds@chromium.org, tebbi@chromium.org
Bug: v8:8880
Change-Id: I44601010491aafcf4c8609fd8c115219317506a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581608
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60983}
This bug does not affect the Torque run on tip-of-tree, but surfaced
in https://crrev.com/c/1196693.
The logic in Stack::DeleteRange was completely wrong and does not work
if the number of moved elements is bigger than the number of deleted
elements.
Change-Id: I5433b3b06e2e54646104493e9bc5e77b9763a521
Reviewed-on: https://chromium-review.googlesource.com/c/1282103
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56676}
