Previously, we had a mixin class PotentiallyConstVariableElement to
represent variables which might be constant. This left some holes in
the type hierarchy which didn't implement
PotentiallyConstVariableElement but nonetheless could be reached by
constant evaluation code in the event of errors in the code being
analyzed, resulting in an invalid cast exception.
This CL drops PotentiallyConstVariableElement and moves its one getter
to VariableElementImpl so that it will be available to all variable
elements. This allows us to avoid a lot of casts, including the one
that previously caused the exception.
Fixes#24645.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1416873003 .
Previously, this method attempted to create a package URI by appending
part of a filesystem path to "package:"; on Windows this resulted in
nonsense URIs like "package:foo\bar.dart".
Now we transform the filesystem paths to "file:" URIs before doing other
computations; this normalizes the path separator to "/", so we can
safely use part of the resulting URIs to construct a "package:" URI.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1416863003 .
Previously we created this element lazily (when requested) but this
didn't work well with the new task model, because creating the element
required calling back into the context and requesting full analysis of
`dart:async` (in order to get access to the Future type), and this
could lead to reentrant task execution.
Now we explicitly create the element in ResolveLibraryTypeNamesTask,
which allows us to get the Future type from the TypeProvider, avoiding
reentrancy.
Fixes#24627.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1405963005 .
We need this to improve code completion, and to *not* suggest method/keywords/etc
in cases like "main() {String s^}". Currently it is parsed as "main() {String; s^;}",
so completion cannot distinguish the variable name "s" from a of start a new expression.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1413773003 .
Fixes#24549.
A few notes:
* does away with registry in favor of context-associated configurations
* pulls in linter rev that does the context association
* bumps analyzer version before publishing (needed to update analyzer_cli)
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1406043002 .
These getters were improperly typed as List<TaskDescriptor>. Due to the
fact that the underlying lists they were returning were List<dynamic>,
and the fact that new warnings for for-in loops haven't been implemented
yet (see commit 89607f06e9), no warnings
or runtime errors alerted us to the incorrect type.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1406583002 .
It's not used yet, except by its own test.
Naturally there's a *lot* to clean up here in follow ups. I tried to keep the ported code in its own directory so it's obvious. Ideally we can remove this directory once the code has been moved out.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1402783004 .
Previously, when attempting to figure out the type of the synthetic
field associated with a getter (or setter),
TypeResolverVisitor.visitMethodDeclaration() used the getters
FunctionTypeImpl.returnType (or FunctionTypeImpl.normalParameterTypes)
to extract the appropriate type. But those getters are only safe to
use after types have been fully constructed (because they may try to
perform type substitution). Fortunately, type substitution isn't
needed here, so we can simply use FunctionTypeImpl.baseReturnType (or
FunctionTypeImpl.baseParameters) instead.
Fixes#24539.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1397193002 .
Note the TODO to fix the extension manager interaction hijinx. Really we should ensure that we are only using the one in engine. At the moment, it's easy to get this wrong (as the initialization heroics herein testify).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1392683003 .
This change paves the way for modifying
pkg/analyzer/tool/task_dependency_graph.dart so that it will be able to
understand the extensibility mechanisms in the task model.
Specifically, it adds the ExtensionPointId annotation, which
task_dependency_graph.dart will be able to use to locate the
TaskDescriptors that are plugged into each task model extension point.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1401543002 .
The problem is that during computing RESOLVED_UNIT3 we reuse RESOLVED_UNIT2
with the previously resolved bodies. And resolver ignores already resolved
identifiers. So, this causes pointing to the stale element model, etc.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1398433004 .
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 .
Paul Berry