Not yet used. This is mostly copied from experiments done earlier in
the year, and is therefore incomplete; I plan to refine this in the
process of fleshing out the implementation and tests.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1410383004 .
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 .
This CL reworks the task model grapher (formerly at
pkg/analyzer/tool/task_dependency_graph.dart, now at
pkg/analyzer/tool/task_dependency_graph/generate.dart) so that it
works similarly to the code generation in the analysis server.
Namely, the output file is stored in source control
(pkg/analyzer/tool/task_dependency_graph/tasks.dot), and a test run by
the buildbots verifies that it is up to date. If it is not, the test
outputs the command necessary to update it.
This carries the benefit that:
- Anyone with access to an installation of graphviz can generate the
task model graph easily from its .dot file.
- Any time a change occurs that affects task model dependencies, a
test failure will prompt us that we need to generate a new .dot
file.
- If a change ever occurs that breaks the ability of the task
dependency grapher to produce the graph, a test failure will prompt
us.
The downside is that when making a change that affects task model
dependencies, it is now necessary to re-run the script
pkg/analyzer/tool/task_dependency_graph/generate.dart to avoid a test
failure.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1408743006 .
Previously, when analyzing the analyzer for task dependency graph
computation, we failed to canonicalize Source URIs into "package:"
URIs. As a result, we failed to properly connect the classes
representing individual classes with the base class AnalysisTask, so
we couldn't find any task classes and produced an empty graph.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1287003006 .
Paul Berry