...instead of ensuring this separately for complete closures of every library.
This improves initial analysis performance from about 44 seconds to 39.
This also makes WorkOrder.moveNext less expensive - to about 5.6% during initial analysis.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1412273004 .
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 .
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 .
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 .
I'm not quite happy that internal classes get into the extension point declaration.
But I guess that because of the nature of the work WorkManager(s) are doing, we have to have significant exposure to internals.
Also, onAnalysisOptionsChanged() and onSourceFactoryChanged()... these probably are better to implement as streams in InternalAnalysisContext.
Thoughts?
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org//1311773005 .
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.
Brian Wilkerson