We haven't quite figured out how we want to store the need for these
type checks in the kernel representation, and I'm hoping that my
coding work can help inform that decision. So for the moment the
annotation is simply stored in the front_end wrapper
(KernelVariableDeclaration). This is enough to get simple tests to
pass.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/3000353002 .
The tests in this CL illustrate the major use cases where runtime
checks are required. They are not exhaustive. In a later CL I will
copy over some of analyzer's internal unit tests, which are much more
thorough.
So far these tests only pass when tested via analyzer, since analyzer
currently is the only platform that does the necessary analysis to
figure out which checks are needed. In follow up CLs I will begin
introducing code into front_end to determine which checks are needed,
and to record this information in the kernel representation.
R=danrubel@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/3002893002 .
In strong mode, when a call to a super-initializer is reordered, we
can use the static type of the super-initializer arguments to set the
types of the temporary variables that we use to do the reordering.
This is desirable because it might help avoid unnecessary casts.
In non-strong mode, we use `dynamic` for the temporary variables, to
replicate Dart 1.0 behavior.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2993193002 .
This is tricky because there isn't a clean correspondence between
analyzer's AST (which reflects user syntax) and kernel representation.
For example:
f(args);
could be a call to a static function f, a method f in the current
class, or an invocation of a function-typed object stored in a
variable called f. ResolutionStorer operates on the kernel
representation, so it sees the difference, but ResolutionApplier
operates on the analyzer AST, so it does not. So we go to some extra
work to make sure a type is stored for f, regardless of whether f is a
function, method, or a variable. This requires some re-ordering logic
in ResolutionStorer, since the inferred type of f is not known until
after the args have been visited.
The implementation is not complete; currently the type that we store
in the first two cases is `dynamic` because the type inference
mechanism doesn't preserve enough information to allow us to determine
the correct type; this will be remidied in a future CL.
A similar situation occurs for:
x.m(args);
which could be a call to a method m in the object x, or an invocation
of a function-typed object returned by the getter m in the object x.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2984013002 .
The type inference engine doesn't even see parenthesized expressions
as a separate entity, since parentheses don't have any semantics. So
we just copy the static type from the enclosed expression.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2982323003 .
This CL propagates types from top level variable declarations into
analyzer ASTs.
This required adding a finishFields method to parser listeners (and a
corresponding method DietListener.listenerFinishFields which calls
it); this allows AnalyzerDietListener to thread the types through from
the BodyBuilder to the AstBuilder. This is similar to what we were
already doing for methods.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2987503003 .
This CL propagates types for simple variable declarations into analyzer ASTs.
Note that for a variable declaration like `int x` we need to store two
pieces of information: the element pointed to by `int`, and the type
of `x`. This CL handles the latter. The former will wait until we
have enough of the element model built that we have an element to
point to.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980053002 .
This code is no longer needed because we no longer run the front end
in "kompile" mode.
Also remove the old expectations files used by the "kompile" tests.
I will remove more code in future CLs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980883003 .
This mode was needed in the early days of the front end when we were
contemplating the idea of building the analyzer AST representation of
code first, and then converting it to kernel. Now that we build
kernel directly, it is no longer needed.
Further CLs will follow to remove code that is no longer used after
this change.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980013002 .
This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).
The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener. The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).
At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax). For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.
In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).
This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`. This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2981693002 .
This CL creates synthetic kernel objects for two additional
BodyBuilder corner cases:
- The synthetic "throw" expression created when code attempts to
construct an abstract class.
- The "throw" expression created when code attempts to assign to a
read-only expression.
With this change, we now create a KernelComplexAssignment object for
all assignments; this has allowed me to streamline the code for
creating assignments slightly.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2972873002 .
Inline instance object hash code into object header on 64 bit.
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it makes the
MegaHashCode part of the Megamorphic benchmark 6 times faster.
This is a reland of https://codereview.chromium.org/2954453002/
which fixes an issue that made script snapshots generated on
64 bit platforms incompatible with 32 bit VMs.
BUG=
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2965723002 .
Note that no actual type inference needs to be performed, but we still
need to implement the _inferStatement() methods so that we can get rid
of the hack in KernelTypeInferrer.inferStatement. Also, we need to
call into the listener so that once this logic is hooked into
AstBuilder, analyzer will stay in sync with type inference.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2962583002 .
Paul Berry