The feature is disabled by default; enable it by setting the option
"enableSuperMixins". (This name was chosen to match the
"--supermixin" flag accepted by the VM).
The feature is not yet exposed through analysis server or the
analyzer_cli.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1262163002 .
Previously, trying to access a static member of a class using '?.' was
not allowed. But the spec was changed in
b11670f899 so that
'ClassName?.staticMember' is now equivalent to
'ClassName.staticMember'.
This CL updates analyzer to follow the spec, and updates the tests in
"tests/language" accordingly. VM and dart2js still need fixing
(see #23794 and #23795).
Fixes#23464.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1255293005 .
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.
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.
- 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.
Konstantin Shcheglov