This CL introduces the code generation tools in analyzer, but leaves analysis_server
untouched. In a later CL, after a new version of analyzer has been
published, I'll refactor analysis_server to point to these tools and
remove the corresponding code from analysis_server.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1411153007 .
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 .
pq