This CL changes the way that the task model does strong mode inference to use the strongly connected components in the import/export graph. Library cycles are computed and inference is staged by forcing each stage of inference to happen across an entire library cycle at once, and to force all external dependencies of a library cycle to have completed inference before inference for the library cycle can begin.
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1386023002 .
Technically, ResolveVariableReferencesTask only requires the
information guaranteed by RESOLVED_UNIT1 to do its job. However,
later tasks, such as ResolveFunctionBodiesInUnitTask, require the
information computed by ResolveUnitTypeNamesTask (which produces
RESOLVED_UNIT3). Normally this is not a problem, because
ResolveFunctionBodiesInUnitTask depends (via a rather complex
dependency chain) upon LIBRARY_ELEMENT5, which in turn depends on
ResolveLibraryTypeNamesTask, which depends on RESOLVED_UNIT3. So
ResolvuUnitTypeNamesTask winds up getting run.
However, it's possible that due to analysis cache pressure, the
resolved unit will get thrown away, while the library element is
preserved. If this happens, then when the resolved unit is being
recomputed, it won't be necessary to run ResolveLibraryTypeNamesTask
in order to recompute LIBRARY_ELEMENT5 (becase LIBRARY_ELEMENT5 is
still cached). As a result, nothing is left that depends on
RESOLVED_UNIT3, so there is nothing to force ResolveUnitTypeNamesTask
to run.
The outward manifestation of this problem is that when trying to
resolve a library, a TypeName will be found whose ".type" property is
unexpectedly null, causing an exception in the ResolverVisitor.
The easy fix is to make ResolveVariableReferencesTask depend on
RESOLVED_UNIT3, so there is a complete dependency chain through all
the RESOLVED_UNIT[N] results that doesn't rely on any
LIBRARY_ELEMENT[N] intermediates.
This is not an ideal fix because it forces us to compute
RESOLVED_UNITs 2 and 3 even if they might not be needed. Fortunately,
computing these RESOLVED_UNITs should be fast, so I don't expect a
significant performance penalty.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1386363002 .
this fixes https://github.com/dart-lang/dev_compiler/issues/356
The issue here is that StrongTypeSystemImpl has toType and fromType backwards from how they are defined on the base class.
The way it works is to read it as "is the first type assignable to the second type"?
(I can see how this may have happened: the base class uses "leftType" and "rightType", which refers to the parameter order, not the order they would appear in an assignment expression.)
R=leafp@google.com
Review URL: https://codereview.chromium.org//1380963004 .
strong mode inference. This CL adds instance fields to the set of variables
for which dependencies are computed, and re-resolves each instance field
initializer using type information inferred for the static variables upon
which it depends.
This CL also stops static variables with existing type information from having
their types overwritten.
This CL ports over a number of the DDC inference tests, more remain to be ported.
There is still at least one outstanding issue with instance variable inference,
see #354 (and the two tests marked fail added in this CL).
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1370793002 .
It was needed only for the old Angular implementation support, which
overlayed its own Element subclasses into normal Dart AST, for example
for string literals - names of components.
As we don't support this anymore, there is no need for the method.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1370833002 .
This CL eliminates the additional typeSystem arguments added to the API by https://codereview.chromium.org/1329743005/ wherever possible, instead projecting out the typeSystem from the context as available. Where not possible, the additional argument is made optional, defaulting to the standard TypeSystemImpl. I believe that the result of this should be backwards compatible for clients (but not implementors) of the API.
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org//1355773002 .
all current and experimental Dart implementations (dart2js, vm, fletch, ddc) get an error in their SDK from this. The CL fixes it by allowing dart:* libraries to implement the disallowed types, like int/double/String/bool.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1346923007 .
Leaf Petersen