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 .
Refactor the AstBuilder to use scriptTag, directives, and declarations
fields rather than pushing top level nodes on a generic stack
and later popping and sorting objects from the that generic stack.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2995963002 .
When dartfmt is run as part of tests to verify that code generation is
up to date, the directory containing the resolved executable is
sometimes .../out/Release.../, but dartfmt is located in
.../out/Release.../dart-sdk/bin/dartfmt. So we need to look in both
the resolved executable directory and in dart-sdk/bin for dartfmt.
R=devoncarew@google.com
Review-Url: https://codereview.chromium.org/3002713002 .
This allows to run flutter gallery example through incremental compiler(it assumes you built android_debug flutter/engine and have fetched flutter/flutter):
$HOME/p/d/dart-sdk/sdk/out/DebugX64/dart --packages=$HOME/p/d/dart-sdk/sdk/.packages $HOME/p/d/dart-sdk/sdk/pkg/front_end/example/incremental_reload/run.dart --sdk-root=$HOME/p/f/t11/flutter/engine/src/out/android_debug/flutter_patched_sdk --input $HOME/p/f/t11/flutter/flutter/examples/flutter_gallery/lib/main.dart
which crashes with
R=sigmund@google.com
error: compilation error: dart:_builtin: Internal problem: Unhandled null in builder.library., #0 internalProblem (package:front_end/src/fasta/problems.dart:29:3)
#1 unhandled (package:front_end/src/fasta/problems.dart:41:10)
#2 DillLoader.buildOutline (package:front_end/src/fasta/dill/dill_loader.dart:47:7)
<asynchronous suspension>
...
Review-Url: https://codereview.chromium.org/2995913002 .
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 CL:
* introduces the Dart API to operate over libraries specifications and describes
the format we intend to use (see libraries_spec.dart)
* implements serialization/deserialization for this API
* switches over the front_end to use these APIs
* public options accept a URI to the JSON file and no longer
accept a `dartLibraries` map
* internal code uses the LibrariesSpecification API
* switches other dependencies on these APIs (resynthesizer_test and patch_sdk.dart)
This is the first step in migrating over to use the libraries.json format and
eventually remove the patched_sdk step. In particular, some of the next steps
include:
* add a build step to generate .json files from .yaml files
* add a libraries.yaml file for the sdk
* split the patched_sdk step in two:
* patching files
* generating .dill files
* add any missing support for patch-files in fasta
* finally remove the patching files step, and only have a build step for generating
.dill files
BUG=
R=ahe@google.com, paulberry@google.com, scheglov@google.com
Committed: https://github.com/dart-lang/sdk/commit/abf2d23af2315fae6dc688741147ef677ec34835
Review-Url: https://codereview.chromium.org/2986303003 .
This reverts commit abf2d23af2.
Reason for revert:
- win build failed in patched_sdk (likely storing paths and not uris)
- dart2js bots failed (missing flag)
Will fix the issues and reland shortly.
Review-Url: https://codereview.chromium.org/2993113003 .
This CL:
* introduces the Dart API to operate over libraries specifications and describes
the format we intend to use (see libraries_spec.dart)
* implements serialization/deserialization for this API
* switches over the front_end to use these APIs
* public options accept a URI to the JSON file and no longer
accept a `dartLibraries` map
* internal code uses the LibrariesSpecification API
* switches other dependencies on these APIs (resynthesizer_test and patch_sdk.dart)
This is the first step in migrating over to use the libraries.json format and
eventually remove the patched_sdk step. In particular, some of the next steps
include:
* add a build step to generate .json files from .yaml files
* add a libraries.yaml file for the sdk
* split the patched_sdk step in two:
* patching files
* generating .dill files
* add any missing support for patch-files in fasta
* finally remove the patching files step, and only have a build step for generating
.dill files
BUG=
R=ahe@google.com, paulberry@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2986303003 .
We need this API to create a mock SDK in a way that makes
ProcessedOptions.validateOptions() to accept it - the SDK root
must exist.
Alternatively (or in addition to) we could make writeXYZ create parent
directories implicitly. So, to "create" a directory, you would need
to create a file in this directory.
R=ahe@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2994643002 .
Paul Berry