Previously, the classes ScopedVisitor, ResolverVisitor,
TypeResolverVisitor, and VariableResolverVisitor each had 4
independently maintained constructors, used respectively by
LibraryResolver (and DDC), the task model, the incremental resolver,
and LibraryResolver2. This was difficult to maintain, and it was
about to get worse with the introduction of diet resolution.
This CL merges the constructors into one, using named optional
parameters where possible to reduce the burden on callers.
A few of the old constructors are kept on a temporary basis because
they are used by DDC, but they are deprecated; these can be removed
once DDC resolution is fully integrated with analyzer.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1207383005.
Previously we computed them during resolution, but this created a
problem: since the set of constructors for a mixin application depends
on the constructors in the superclass, and the superclass might itself
be a mixin application, it might theoretically be necessary to analyze
all files in the transitive import/export closure before it is
possible to compute the set of constructors for a class. As a result,
in order to produce completion results after a non-incremental change
to file X, we have to re-analyze the entire transitive closure of
files importing or exporting X. This takes prohibitively long.
This change moves the computation into the ClassElement.constructors
getter. The computation is not cached, so now a change to file X only
requires rebuilding the element models for files directly importing X
(or directly importing files that contain X in their transitive export
closure).
Since the result of the computation is not cached, this will produce
an increase in analysis time, however since mixin applications are
used so rarely, the performance impact should be negligible.
Fixes#23732.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1215053003.
This splits BuildSourceClosuresTask into BuildSourceExportClosureTask,
which produces EXPORT_SOURCE_CLOSURE, and
BuildSourceImportExportClosureTask, which produces
IMPORT_EXPORT_SOURCE_CLOSURE. IMPORT_SOURCE_CLOSURE is no longer
computed, since it was not being used.
This should reduce the amount of analysis work that needs to be rerun
before we can produce code completions, since we will no longer have
so recompute the import/export source closure (which could potentially
need recomputation for a large number of files) until just prior to
ResolveUnitReferencesTask, which in theory doesn't need to run in
order to produce code completions.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1220743004.
- ResolveLibraryTypeNamesTask doesn't need to depend on RESOLVED_UNIT3
for all sources in the transitive closure of imports; it only needs
RESOLVED_UNIT3 for the units constituting the current library.
- ResolveVariableReferencesTask doesn't need to depend on
LIBRARY_ELEMENT6 for all libraries in the transitive closure of
imports, because it only resolves references to locals and
parameters, and they can only resolve to elements in the same
compilation unit; the transitive closure is not needed until
ResolveUnitReferencesTask.
- ResolveVariableReferencesTask doesn't need LIBRARY_ELEMENT6 of the
current library, since it only needs the LibraryElement to
initialize the scope chain; LIBRARY_ELEMENT1 is sufficient.
- ResolveVariableReferencesTask doesn't need RESOLVED_UNIT3 of the
current library, since it only needs to ensure that the elements for
locals and parameters have been built; RESOLVED_UNIT1 is sufficient.
This should help reduce the amount of analysis which has to be
performed before code completions can be produced.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1212503004.
Commit f8ce36df55 introduced an SDK
class called "Resource", causing warnings to appear in any files that
reference the analyzer class with the same name. (Fortunately there
was no regression in functionality since the spec requires the name
conflict to be resolved in favor of the definition that is outside the
SDK).
As a short term workaround to avoid the warnings, we are explicitly
importing 'dart:core' and hiding the new Resource class. In a future
CL, we plan to rework analyzer's Resource class in order to make some
changes necessary for ".packages" file support; when that happens we
will probably rename the class to avoid the name conflict.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1215753003.
As of commit 67b99e4b33, it is now
consistently a compile error for a prefix not to be followed by '.'.
(Previously, there were two exceptions in which a prefix not followed
by '.' was treated as though it was preceded by "this.")
This CL updates analyzer to be consistent with the new spec langauge,
and modifies the tests in tests/language accordingly.
Dart2js and the VM do not yet produce the correct compile-time error
in all circumstances. See issues #23611 and #23612.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1186033004.
Previously, the least upper bound code was only half-written--it
computed correct results if both types were interface types, and
otherwise returned null. Now we always return a non-null type.
Unfortunately, the full least upper bound algorithm in the spec
requires referencing types not reachable from the types being
compared; thus in order to execute it we need access to the
TypeProvider. We can't do this with the existing API. So that API
has been deprecated. The new API uses a class TypeSystem which
contains a pointer to the TypeProvider. This new class should also be
a useful starting point in case we need to make the type system more
pluggable in the future.
Clients that use the old API will see no change in behavior--they will
still get the half-written algorithm.
Still to be addressed in future CL's:
- Deprecate getSmartLeastUpperBound.
- Fix calls to getLeastUpperBound and getSmartLeastUpperBound in analysis
server.
- Implement least upper bound computation for function types.
- Make sure type parameters function correctly in the presence of F-bounded
polymorphism.
- Implement shared tests.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1179343004.
Konstantin Shcheglov