The CallToRuntime stub is not needed as a fixed entry anymore since
all stubs set up their own object pool.
The UpdateStoreBuffer stub is still needed because intrinsics don't set
up a normal frame. Changing that would also allow removing this entry.
BUG=
R=srdjan@google.com
Review URL: https://codereview.chromium.org//1215143002.
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.
* report mean, 90th, 99th, and std-dev
* increase analysis wait time to 60 seconds
* add option for analysis server localhost diagnostics
* report running old vs new task model
* do not check if src dir exists so that scripts are more portable
* set clientRequestTime for each request
* ensure dir paths have trailing separators
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1221893003.
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.
Previously the dependency was a private implementation detail of
_SourceClosureTaskInputBuilder, which made it difficult to statically
analyze the input/output relationships between tasks in the task
model.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1216523003.
Narrowing of ranges should only occur if the new range is actually
narrower than the old range. It can happen that a symbolic range
is worse than the already computed one. Ignore the new range in this
case.
BUG=dartbug.com/23693
R=vegorov@google.com
Review URL: https://codereview.chromium.org//1219623004.
Stephen Adams