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}

In the generated CSA, we called overloaded macros while relying on CSA
subtyping of TNodes. This doesn't work well with overloads, because
for C++ any TNode subtyping is treated as an implicit conversion, which
makes these calls ambiguous for C++.
As a solution, we insert implicit_cast conversions for arguments
according to the type predicted by Torque. This way, a CSA overload is always
called with exactly the signature declared in base.tq.
This has the additional benefit that it validates the signatures declared in
base.tq, which could previously be too permissive.
Also, this triggered a bug in structs, where VisitResult's were
carrying the wrong type.

Bug: v8:7793
TBR: danno@chromium.org
Change-Id: I8ed4bfd04793c8a8805a4a3dd5cf2a85c20ce786
Reviewed-on: https://chromium-review.googlesource.com/1165237
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54948}

This also fixes all resulting failures.

Bug: v8:7965
Change-Id: I5451cdd3a3ec48c708107a22445808c268efe861
Reviewed-on: https://chromium-review.googlesource.com/1148336
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54643}

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 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}

Only pass around the unadulterated value identifier in the VisitResult class
until the very last moment before code generation, at which point the
declaration that was used to originally define the value is used to generate the
correct final source code string in the context of a l-value or r-value.

Bug: v8:7793
Change-Id: Ifd0c0d245b2eb65c7f3ddb1ad4c87ee235c54a82
Reviewed-on: https://chromium-review.googlesource.com/1125063
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54229}

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}

In the process, add a utility functions to automate printing out comma-separated
lists. Also make sure that the << operator applies to "const Type&" rather than
"const Type*" for consistency elsewhere and generally just good practice.

Bug: v8:7793
Change-Id: I488e8383c4a9496552e63601738d6bcca0ca6e80
Reviewed-on: https://chromium-review.googlesource.com/1111854
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54038}

This CL adds a 'constexpr String' type to Torque, which gets compiled
to 'const char*'.

It makes it easier to pass strings around in Torque files,
especially when trying to Print() them.

Bug: v8:7793
Change-Id: I2d4feac7012f5401f2b467475f8df086e46ac18a
Reviewed-on: https://chromium-review.googlesource.com/1104466
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53814}

In the process:
 - Make it possible to add 'otherwise' labels to operators
 - operators can be defined by non-external macros

Bug: v8:7793
Change-Id: Ia16ae7c95a4719703c80a927dee44c74b65c170b
Reviewed-on: https://chromium-review.googlesource.com/1100826
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53754}

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}

In Torque, we have several global singleton classes. Using the contextual
variable pattern instead of passing around pointers in random places
makes the code more readable.
This CL does this for TypeOracle, we plan to do it for more classes in
the future.

Bug: v8:7754
Change-Id: Ib744b476ce51a4932c52274b2210149515f1663d
Reviewed-on: https://chromium-review.googlesource.com/1078729
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53444}

This adds support for union types to Torque.

There is a new type expression
A | B
to form the union of the type expressions A and B.
This is only possible if A and B have a common supertype, to prevent
nonsensical unions of types with different representations.

Union types are normalized:
A | B == B | A
A | (B | C) == (A | B) | C
A | A == A

The subtyping rules are defined recursively:
(A | B) <: C  if  A <: C and B <: C
A <: (B | C)  if  A <: B or A <: C

This allows to define Object as a union type:

type Tagged generates 'TNode<Object>';
type Smi extends Tagged generates 'TNode<Smi>';
type HeapObject extends Tagged generates 'TNode<HeapObject>';
type Object = Smi | HeapObject;

The type {Tagged} is introduced to have a common supertype of all
tagged values, but we should not use it directly, because {Object}
contains the additional information that there is nothing but {Smi}
and {HeapObject} values.

When mapping union types to CSA types, we select the most specific
common supertype. For Number and Numeric, we already use union types
on the CSA side. Since it is not possible to map to CSA union types
in general, we special-case these two union types to map them to
the CSA union types we already use.

Bug: v8:7793
Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908
Reviewed-on: https://chromium-review.googlesource.com/1076132Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53411}

Bug: v8:7754
Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b
Reviewed-on: https://chromium-review.googlesource.com/1071654Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53398}

We already had to introduce TypeAlias to allow types to be const.
With TypeAlias, there is no need for types to be declarable themselves.

Change-Id: Ia718482f6c121b5316aca819368e6d048283e5e8
Reviewed-on: https://chromium-review.googlesource.com/1068734
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53282}

Fixes known issue that specialization doesn't rigorously checked to
verify that specialization signature precisely matches generic
declaration.

Change-Id: I884f7f16a467ab716d2b0c553485f4b1c55ed806
Reviewed-on: https://chromium-review.googlesource.com/1063613Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53252}

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}

Change-Id: I61a594e194082577135dbc82b2673bf477105ef3
Reviewed-on: https://chromium-review.googlesource.com/1046949
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53050}

Torque expressions of type constexpr are evaluated at compile-time
rather than runtime. They are backed by C++ types rather than
TNode<X> types, so the macro functions that are called by generated
C++ code expect values to be computed when the snapshot is generated
rather than by TurboFan-generated code.

Specifically, "if" statements can have a constexpr modifier. With this
modifier, a type of "constexpr bool" is expected rather than "bool",
and in that case instead of generating a CSA BranchIf, it generates
a C++ "if (<bool expression>)" that generates code for only the true or
false path based on the bool value at torque-execution (compile time)
rather than generating both paths (including inserting phi nodes
for variables modified on either branch at the re-merge at the end
of the if) and dynamically dispatching to the true or false path
during d8/Chrome/node.js execution (runtime) using a CSA BranchIf.

Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d
Reviewed-on: https://chromium-review.googlesource.com/1042085
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53001}

This is a preparatory step for implementing generics. Along the way, clean up
and encapsulate a bunch of code, including:

* Fully encapsulate Scope by adding the new class ScopeChain that provide an
  abstraction for creating and activating scopes.
* Untangle Modules and Scopes.
* Unify scope activation so that it is always associated with an AST node
  and triggered by a RAII helper class.
* Unify (somewhat) how builtins and macros are created, fixing a few
  inconsistencies with when and how parameters and their types are declared.
* Create a new Declarations class that brokers between the visitor classes and
  the ScopeChain. This moves handling of declaration-related errors out of the
  visitors but also makes it possible to do so without polluting Scope and
  ScopeChain with details about resolving SourcePositions in error cases.

Change-Id: I180017d4cf39ccf5ef1d20b84f53284c252f8d87
Reviewed-on: https://chromium-review.googlesource.com/1038504
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52947}

Bug: v8:7666
Change-Id: Ida9b6f964261bad75a4eb5d567ad37ec82569bcc
Reviewed-on: https://chromium-review.googlesource.com/1023061
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52751}

An overview of motivation behind Torque and some of its principles
can be found here: https://bit.ly/2qAI5Ep

Note that there is quite a bit of work left to do in order to get
Torque production-ready for any non-trivial amount of code, but
landing the prototype as-is will allow for much faster iteration.

Bugs will be filed for all of the big-ticket items that are not
landing blockers but called out in this patch as important to fix.

Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73
Reviewed-on: https://chromium-review.googlesource.com/845682
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52618}