In the new task model, use explicit dependencies on the type provider.

pkg/analyzer/lib/src/task/manager.dart

Index: pkg/analyzer/lib/src/task/manager.dart
diff --git a/pkg/analyzer/lib/src/task/manager.dart b/pkg/analyzer/lib/src/task/manager.dart
index eebc08491fdea0fa1ef13f0b43babc5de5cf7d7a..64b8055eff42b70f4d70ba848e0f30fe3c7c36ea 100644
--- a/pkg/analyzer/lib/src/task/manager.dart
+++ b/pkg/analyzer/lib/src/task/manager.dart
@@ -33,6 +33,13 @@ class TaskManager {
   Set<ResultDescriptor> priorityResults = new Set<ResultDescriptor>();
 
   /**
+   * Indicates whether any tasks are currently being performed (or building
+   * their inputs).  In debug builds, we use this to ensure that tasks don't
+   * try to make use of the task manager in reentrant fashion.
+   */
+  bool isTaskRunning = false;

[scheglov, 2015/05/13 21:49:09]

I'm not sure that this is the best place for this flag.
TaskManager works like a contains for tasks, not a runner of them.

[Paul Berry, 2015/05/14 17:11:01]

Where do you think would be better?  I'm open to suggestions, but I didn't
really have any better ideas.

I'll land the CL as is for now; I'm happy to do a follow-up if/when we find a
better place.

[scheglov, 2015/05/14 17:13:04]

Maybe WorkOrder or AnalysisDriver.

[Paul Berry, 2015/05/14 17:27:33]

WorkOrder doesn't work because we create fresh work orders all the time--we need
a singleton object in order to verify that we're not reentrant.

AnalysisDriver is a possibility, but it's a bit ugly because it's hard to get to
the AnalysisDriver from the WorkItem.

I've uploaded an alternate version of the patch which uses AnalysisDriver. 
(Unfortunately the delta from patch set 2 is a bit confusing because I also did
a rebase).  PTAL and let me know what you think.

+
+  /**
    * Add the given [result] to the list of results that are to be computed for
    * all sources within an analysis root.
    */