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 .
The fasta parser generates begin/end event pairs such as
[beginCompilationUnit] and [endCompilationUnit].
Each event should be generated "within" a "higher level" begin/end event pair,
except for [beginCompilationUnit] and [endCompilationUnit],
which should not be generated within any begin/end event pair.
This CL updates the fasta test listener and associated test code to assert that
[endTopLevelDeclaration] is generated within or is enclosed by
a begin/end "CompilationUnit" event pair, and that the [beginCompilationUnit]
and [endCompilationUnit] events are not enclosed by any begin/end event pairs.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2993833002 .
The API for pkg/front_end is still in flux so we want to avoid having
any packages depend directly on it (other than analyzer and
back-ends).
This CL re-exports some of the critical pieces of front_end needed by
analyzer clients so that those clients can access them via analyzer,
without having to directly depend on front_end. It also updates
pkg/analyzer_plugin to make use of those re-exports.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2993123002 .
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: abf2d23af2
Review-Url: https://codereview.chromium.org/2986303003 .
This CL begins removing gyp from Dart's tree.
Removing gyp will go in three stages:
1. Remove unused .gyp and .gypi files.
2. Translate *_sources.gypi files to *_sources.gni files
3. Remove //third_party/gyp from DEPS
This CL is stage 1.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2992593002 .
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 .
Implement forEachParameter in closures, deal with not all closures being localFunctions, and point to the constructor head instead of body when calling "getConstructorBody"
This reverts commit b74f53aa74.
BUG=
R=sra@google.com
Review-Url: https://codereview.chromium.org/2999453002 .
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 .
For the migration script, I need a (less hacky) way of programmatically
modifying a status file. As a step along that path, I need the ability
to write a status file to disc given a StatusFile object.
With that, it was a small step to write a little "formatter" that turns
a status file into its canonical representation.
It removes unneeded parentheses in expressions, normalizes expectation
case, and normalizes whitespace. Seems useful.
R=whesse@google.com
Review-Url: https://codereview.chromium.org/2988383002 .
