Create a task in the new task model to compute constant dependencies.

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

Index: pkg/analyzer/lib/src/task/dart.dart
diff --git a/pkg/analyzer/lib/src/task/dart.dart b/pkg/analyzer/lib/src/task/dart.dart
index 4b88e7df31b04b55abc226ba834cd80a91e57cc7..a5ec7254c93e6e6e43115b760c2a3796f1310111 100644
--- a/pkg/analyzer/lib/src/task/dart.dart
+++ b/pkg/analyzer/lib/src/task/dart.dart
@@ -8,6 +8,7 @@ import 'dart:collection';
 import 'dart:math' as math;
 
 import 'package:analyzer/src/generated/ast.dart';
+import 'package:analyzer/src/generated/constant.dart';
 import 'package:analyzer/src/generated/element.dart';
 import 'package:analyzer/src/generated/engine.dart' hide AnalysisTask;
 import 'package:analyzer/src/generated/error.dart';
@@ -1640,6 +1641,79 @@ class BuildTypeProviderTask extends SourceBasedAnalysisTask {
 }
 
 /**
+ * A task that computes [CONSTANT_DEPENDENCIES] for a constant.
+ */
+class ComputeConstantDependenciesTask extends AnalysisTask {
+  /**
+   * The name of the [RESOLVED_UNIT] input.
+   */
+  static const String UNIT_INPUT = 'UNIT_INPUT';

[Brian Wilkerson, 2015/05/07 22:46:59]

Perhaps "RESOLVED_UNIT_INPUT" to be consistent?

[Paul Berry, 2015/05/08 00:24:35]

Personally I don't see much benefit in the longer name, since the names are
local to the task.  Also, most of the existing tasks that take a RESOLVED_UNIT
as an input call it UNIT_INPUT.

Leaving as is for now.

+
+  static final TaskDescriptor DESCRIPTOR = new TaskDescriptor(
+      'ComputeConstantDependenciesTask', createTask, buildInputs,
+      <ResultDescriptor>[CONSTANT_DEPENDENCIES]);
+
+  ComputeConstantDependenciesTask(
+      InternalAnalysisContext context, AnalysisTarget target)
+      : super(context, target);
+
+  @override
+  String get description {
+    Source source = target.source;
+    String sourceName = source == null ? '<unknown source>' : source.fullName;
+    return '${descriptor.name} for element $target in source $sourceName';
+  }
+
+  @override
+  TaskDescriptor get descriptor => DESCRIPTOR;
+
+  @override
+  void internalPerform() {
+    //
+    // Prepare inputs.
+    //
+    // Note: UNIT_INPUT is not needed.  It is merely a bookkeeping dependency
+    // to ensure that resolution has occurred before we attempto to determine

[Brian Wilkerson, 2015/05/07 22:46:59]

"attempto" --> "attempt to"

[scheglov, 2015/05/07 22:52:09]

attempto -> attempt

[Paul Berry, 2015/05/08 00:24:35]

Done.

+    // constant dependencies.
+    //
+    Element element = target;
+    AnalysisContext context = element.context;
+    TypeProvider typeProvider = context.typeProvider;

[Brian Wilkerson, 2015/05/07 22:46:59]

I believe that you want to have a TYPE_PROVIDER input rather than getting the
type provider directly from the context.

[Paul Berry, 2015/05/08 00:24:35]

Hmm, I believe you are right, since some analysis of dart:core and dart:async
needs to be done before the type provider can be returned.  I will address this
in a follow-up CL.

Should my follow-up CL make this change to all tasks?  I notice that
GenerateHintsTask, ResolveReferencesTask, ResolveUnitTypeNamesTask,
ResolveVariableReferencesTask, and VerifyUnitTask all get the type provider
directly from the context.

[scheglov, 2015/05/08 03:53:00]

I don't think we want to request all information we want to access as _direct_
inputs.

For example here we request RESOLVED_UNIT.
But we don't request also RESOLVED_UNIT1, RESOLVED_UNIT2, etc.
The reason is that we know that RESOLVED_UNIT will also have all information
prepared for RESOLVED_UNIT1, RESOLVED_UNIT2, etc.

In the same way RESOLVED_UNIT means that TYPE_PROVIDER was computed for the
context, because every RESOLVED_UNIT is created from RESOLVED_UNIT2, and every
RESOLVED_UNIT2 requests TYPE_PROVIDER.

[Brian Wilkerson, 2015/05/08 14:11:29]

But not doing so could (although I admit the probability is small) cause
problems later when we change the task structure to improve performance.
Basically, we're hard-coding the assumption that a previous task had depended on
the type provider, and that seems dangerous (though again, the risk is
admittedly low).

Is there a reason to *not* make the dependency explicit?

[scheglov, 2015/05/08 15:14:36]

No, there isn't.
Just consistency.

+    //
+    // Compute dependencies.
+    //
+    List<Element> dependencies = <Element>[];
+    new ConstantEvaluationEngine(typeProvider, context.declaredVariables)
+        .computeDependencies(element, dependencies.add);
+    //
+    // Record outputs.
+    //
+    outputs[CONSTANT_DEPENDENCIES] = dependencies;
+  }
+
+  /**
+   * Return a map from the names of the inputs of this kind of task to the task
+   * input descriptors describing those inputs for a task with the
+   * given [target].
+   */
+  static Map<String, TaskInput> buildInputs(Element target) {
+    return <String, TaskInput>{
+      UNIT_INPUT: RESOLVED_UNIT
+          .of(new LibrarySpecificUnit(target.library.source, target.source))
+    };
+  }
+
+  /**
+   * Create a [ResolveReferencesTask] based on the given [target] in
+   * the given [context].
+   */
+  static ComputeConstantDependenciesTask createTask(
+      AnalysisContext context, AnalysisTarget target) {
+    return new ComputeConstantDependenciesTask(context, target);
+  }
+}
+
+/**
  * A task that computes a list of the libraries containing the target source.
  */
 class ContainingLibrariesTask extends SourceBasedAnalysisTask {