Skip to content

V
V8
Switch branch/tag
  1. 11 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] add references to HeapObject fields. · a9a1a3bb
      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: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60780}
      a9a1a3bb
  3. 04 Apr, 2019 2 commits
    • Daniel Clifford's avatar
      [torque] Indexed class field initialization · 62a32805
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60639}
      62a32805
    • Tobias Tebbi's avatar
      [torque] named arguments for constructors · e87e3b1f
      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: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60622}
      e87e3b1f
  5. 03 Apr, 2019 1 commit
  7. 27 Feb, 2019 2 commits
  9. 15 Feb, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] make overload resolution robust concerning branching contexts · 93c13714
      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: 's avatarPeter Wong <peter.wm.wong@gmail.com>
Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59625}
      93c13714
  11. 07 Feb, 2019 1 commit
  13. 06 Feb, 2019 2 commits
  15. 05 Feb, 2019 1 commit
  17. 04 Feb, 2019 1 commit
  19. 22 Jan, 2019 3 commits
    • Daniel Clifford's avatar
      Reland "[torque] Implement safe initialization of classes through hidden structs" · 4c9bc648
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59005}
      4c9bc648
    • Daniel Clifford's avatar
      Revert "[torque] Implement safe initialization of classes through hidden structs" · 8c17e114
      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: 's avatarDaniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58980}
      8c17e114
    • Daniel Clifford's avatar
      [torque] Implement safe initialization of classes through hidden structs · d11a0648
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58979}
      d11a0648
  21. 17 Jan, 2019 2 commits
  23. 16 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Implement methods and constructors for structs and classes · b615dfa5
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58860}
      b615dfa5
  25. 17 Dec, 2018 1 commit
  27. 14 Dec, 2018 1 commit
    • Daniel Clifford's avatar
      [builtins] Port GetArgumentsFrameAndCount to Torque · a74afec6
      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: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58253}
      a74afec6
  29. 07 Dec, 2018 1 commit
  31. 27 Nov, 2018 1 commit
  33. 19 Nov, 2018 1 commit
  35. 14 Nov, 2018 1 commit
  37. 13 Nov, 2018 1 commit
  39. 09 Nov, 2018 1 commit
  41. 05 Nov, 2018 2 commits
    • Tobias Tebbi's avatar
      [torque] allow qualified access to different modules/namespaces · ece9156c
      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: 's avatarDaniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57238}
      ece9156c
    • Tobias Tebbi's avatar
      [torque] cleanup generics and scopes · 06c8ce59
      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: 's avatarDaniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57231}
      06c8ce59
  43. 31 Oct, 2018 4 commits
  45. 24 Oct, 2018 1 commit
  47. 08 Oct, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Allow atomarStatements in otherwise statements · 6f5600e2
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56447}
      6f5600e2
  49. 04 Oct, 2018 1 commit
  51. 24 Sep, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Improve formatting in format-torque · f088840a
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56158}
      f088840a
  53. 11 Sep, 2018 1 commit
  55. 10 Sep, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] disallow using logical operators in value contexts · e569438b
      Tobias Tebbi authored 
      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/1215162Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55750}
      e569438b
  57. 13 Aug, 2018 1 commit
  59. 08 Aug, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] add typeswitch statement · 91ef86f9
      Tobias Tebbi authored 
      This adds a typeswitch statement

typeswitch (e)
case (x1 : Type1) {
  ...
} case (x2 : Type2) {

} ...
... case (xn : TypeN) {
  ...
}

This checks to which of the given types the result of evaluating e can
be cast, in the order in which they are listed. So if an earlier
type matches, a value of this type won't reach a later case.

The type-checks are performed by calling the cast<T>() macro.
The type of the argument passed to the cast macro is dependent on the
case and excludes all types checked earlier. For example, in

const x : Object = ...
typeswitch (x)
case (x : Smi) {
  ...
} case (x : HeapNumber) {
  ...
} case (x : HeapObject) {
  ...
}

there will be calls to cast<Smi>(Object) and
cast<HeapNumber>(HeapObject), because after the Smi check we know that
x has to be a HeapObject. With the refactored base.tq definition of
cast, this will generate efficient code and avoid repeating the Smi
check in the second case.

The type system ensures that all cases are reachable and that the type
given to the last case is safe without a runtime check (in other words,
the union of all checked types covers the type of e).

The cases can also be written as
case (Type) { ... }
, in which case the switched value is not re-bound with the checked
type.

Bug: v8:7793
Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3
Reviewed-on: https://chromium-review.googlesource.com/1156506
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54958}
      91ef86f9