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 .
Currently, fasta synthetically closes open braces until it finds
a match for the current closing brace. This works most of the time,
but provides less than optimal recovery in some common cases.
For example, given the following
class { foo()){print(a);} var a = 'hello'; }
the current brace recovery method fails to find any match for the
second closing parenthesis and synthetically closes the class
causing the rest of the file to be parsed as outside the class.
With this CL, fasta still synthetically closes open braces when it finds
a match for the current closing brace, but if there is no match, then
it just skips over the extra closer and continues. This approach dramatically
improves recovery in many cases where there is an extra closing parenthesis
or extra closing square bracket. In the example above, fasta parses
everything after the second closing parenthesis inside the class.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2981343002 .
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 .
It is informative in the same way as documentation.
Yesterday I tried to make Analyzer and Analysis Server stop using
FieldFormalParameterElement(s) and found one important use case requested
by the Flutter team. We need to show documentation of a field when
user requests documentation on the corresponding field formal named
parameter. This happens outside of the file that declares the parameter
and the field, so we don't have AST available. Of course we could
resolve the unit, but it would cost us something. And if we decide
that it is OK, then maybe we don't need to have documenation comments
in elements at all.
This is of course more convenience, and we could store documentation
and parameter to field mappings outside, like we store index. Just a
compromise - convenience vs. purity.
R=ahe@google.com, kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2983173002 .
Konstantin Shcheglov