Original CL had a bug that wasn't visible unless you delete your
out/ReleaseX64/patched_sdk folder.
Patchset #1 is the original CL, patchset #2 shows the fix.
This reverts commit 4aadfe09df.
BUG=
Review-Url: https://codereview.chromium.org/2976543002 .
This CL tweaks the public APIs in package:front_end, and
starts using those APIs outside the package. For example, this
removes 9 uses of DillTarget, so it is not longer mentioned
outside pkg/front_end and the analyzer_target.
Actual changes:
- in package:front_end
* added kernel_generator_impl: new file contains code that
used to be in kernel_generator. Code has some modifications:
it uses a single canonical-root when loading summaries, and
it supports generating both outlines and kernel in one go.
* removed code that didn't belong here:
a. most of calculating deps for .GN moved to patch_sdk
b. vm-specific outcomes moved to kernel-service
* updated how `native` is implemented, so we can more easily
support dart2js and ddc
* updated how we check where `int`, `bool`, etc can be implemented.
* added support "hermetic mode" in modular builds
('chaseDependencies = false' option)
* moved `trim` step out of fasta, and for now call it only within
the public API. This is not yet exposed, and I stopped covering it in
most tests (now only covered in shaker tests). The plan is to add
tests for the public API covering this in the future.
* removed `uriToSource` when serializing outlines
* added unit tests for public APIs
- patch_sdk
* use the public API to craete platform.dill, outline.dill (now
500K insted of 3Mb because it excludes sources), and vmservice_io.dill
* moved here logic internal to .GN
- kernel service
* use the public API
* moved here logic that depends on VM internals (e.g. status enum,
compilation results)
- package:compiler
* use the public API in tools and unit tests
* simplified patched-sdk generation: no more extending fasta's internals
- package:kernel
* fix bug in deserialization: initializers and other lists were
overwritten accidentally with external definitions.
* updated unit tests, moved shared logic to frontend/src/fasta/testing
R=johnniwinther@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2953703002 .
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 .
* update test because fasta scanner correctly warns on 1.e+2
* fasta scanner correctly produces compile time error
see dartbug.com/28664
fix dartbug.com/28680
* update fasta AsciiControlCharacter error code
* enable fasta scanner in analyzer by default
R=ahe@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2967363003 .
We introduce a class KernelSyntheticExpression which can be used for
synthetic expressions introduced by the front end. It is used for
expressions that represent errors detected by the front end, and it is
also the base class for KernelComplexAssignment. By default, type
inference skips these synthetic expressions, inferring a type of
`dynamic`. (Note, however, that classes dervied from
KernelComplexAssignment override this behavior).
We also introduce a class KernelSyntheticStatement which behaves
similarly, but is used for statements rather than expressions,
e.g. the synthetic assignment introduced at the top of a "for" loop
whose loop variable is defined elsewhere.
Finally, we modify KernelTypeInferrer.inferFieldTopLevel() so that it
deliberatly infers `dynamic` for fields that lack an initializer.
Previously this behavior happened as a result of the hack in
KernelTypeInferrer.inferExpression which caused type inference to
infer `dynamic` for anything that didn't implement KernelExpression.
All of these changes should help pave the way for removing the
aforementioned hack.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2968563002 .
This is intended for profiling, to ensure that type inference and type
promotion do not slow down compilation too much.
Currently the option is just plumbed through to the kernel Target
class since I'm not exactly sure how we'll want to enable/disable this
option; we can plumb it the rest of the way in a future CL.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2962913002 .
All variable declarations encountered by type inference are now of
type KernelVariableDeclaration, so we no longer need a hack to handle
ordinary VariableDeclaration objects.
Removing the hack avoids covering up bugs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2961723002 .
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 .
I implemented the correct logic for both SuperPropertyGet and
DirectPropertyGet, since there are TODO comments in the code
indicating that the former will be replaced by the latter when
possible.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2959823002 .
I implemented the correct logic for both SuperMethodInvocation and
DirectMethodInvocation, since there are TODO comments in the code
indicating that the former will be replaced by the latter when
possible.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2954403002 .
Note that since the first argument of an assert statement may be
either of type `bool` or `() -> bool`, and the second argument may be
any object, no type context is passed down in downward inference; the
only inference we need to do is to recursively invoke
`inferExpression` to ensure that subexpressions are inferred properly.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2959763002 .
Analyzer does not infer switch cases correctly (it uses an empty
context for the case expression, instead of the type of the switch
expression), so the tests are in inference_new.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2953423002 .
Peter von der Ahé