Previously this was working for a few use cases by dumb luck, but it
wasn't well tested and became broken by
b29c6bf330. This CL fixes it for real
and adds tests to verify the fix.
Note that there is a change to how we represent an unresolved
import/export: instead of storing a URI_EXISTS modifier in the element
model, we simply mark the imported library element as synthetic.
(This library element existed anyway; we just weren't marking it as
synthetic). This makes it easy to tie in with summaries, since it is
easy for the resynthesizer to detect that the library doesn't exist at
the time the library handle is resolved.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2235373003 .
Consider libraries `A`, `B`, and `C`, where `C` imports `B`, and `B`
exports `A`. [RESOLVED_UNIT4] of `C` depends on [LIBRARY_ELEMENT4] of
[IMPORTED_LIBRARIES], i.e. `B`. Even though [LIBRARY_ELEMENT4] of `B`
depends on [LIBRARY_ELEMENT3]s of its [EXPORT_SOURCE_CLOSURE] (i.e. `A`
and `B`), [RESOLVED_UNIT4] of `C` sees only [LIBRARY_ELEMENT4] of `B`.
When invalidate results of `B` (but keep results of `C`), we will
invalidate and remove [LIBRARY_ELEMENT4] of `B`, so we lose knowledge
that [RESOLVED_UNIT4] of `C` indirectly depends on `A`.
The solution is do depend on [EXPORT_SOURCE_CLOSURE] of all
[IMPORTED_LIBRARIES] in [RESOLVED_UNIT4] of `C`.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2171673002 .
- Regenerate tasks.dot
- Mark a test as passing that previously failed
(fail_finalPropertyInducingVariable_classMember_instance_unprefixed)
Note that there are three other tests that I would have expected to
start passing as well (see
fail_finalPropertyInducingVariable_classMember_instance_*), but they
still fail.
TBR=scheglov@google.com
Review URL: https://codereview.chromium.org/1469093002 .
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 .
Brian Wilkerson