Strong mode checker integration

pkg/analysis_server/lib/src/status/get_handler.dart

Index: pkg/analysis_server/lib/src/status/get_handler.dart
diff --git a/pkg/analysis_server/lib/src/status/get_handler.dart b/pkg/analysis_server/lib/src/status/get_handler.dart
index 394ad780d9a5b51c6f8c4f15a25b3ca096eb0f6d..3822636b5354abd191163bc81b79eea6d116888b 100644
--- a/pkg/analysis_server/lib/src/status/get_handler.dart
+++ b/pkg/analysis_server/lib/src/status/get_handler.dart
@@ -271,6 +271,14 @@ class GetHandler {
     if (unit != null) {
       return unit;
     }
+    unit = entry.getValue(RESOLVED_UNIT9);

[Leaf, 2015/10/13 05:35:47]

I clearly missed this in a previous renumbering CL.  These hardcoded lists feel
really brittle to me.  It seems like in so far as the internal tasks of the task
model bleed out of dart.dart at all, it would be good to do so programmatically
in some way.  For example, maybe exposing one list of results (or a few
different results of the different kinds) that code like this could just iterate
over?  

[Brian Wilkerson, 2015/10/13 14:21:19]

I agree. This is very brittle and it's on the list of things that need to be
fixed.

We could probably even just iterate over the values in the entry and return the
first one that is a CompilationUnit (I haven't thought through the implications
for plugins).

+    if (unit != null) {
+      return unit;
+    }
+    unit = entry.getValue(RESOLVED_UNIT10);
+    if (unit != null) {
+      return unit;
+    }
     return entry.getValue(RESOLVED_UNIT);
   }
 
@@ -337,7 +345,10 @@ class GetHandler {
       results.add(RESOLVED_UNIT6);
       results.add(RESOLVED_UNIT7);
       results.add(RESOLVED_UNIT8);
+      results.add(RESOLVED_UNIT9);

[Jennifer Messerly, 2015/10/13 15:23:52]

I forgot to ask yesterday ... do we need the old BASIC trick of numbering things
"100" "200" so we can add numbers in between later? Or maybe floating point? ;-)

I guess this is a silly way of asking: if we could have names instead of
numbers, that would help my forgetful brain.

Anyway, not an issue with your CL in particular but I wanted to mention it.

[Brian Wilkerson, 2015/10/13 15:37:37]

Yes, the names are poor. I'm currently in the process of documenting better what
each means, and that might help us find better names.

+      results.add(RESOLVED_UNIT10);
       results.add(RESOLVED_UNIT);
+      results.add(STRONG_MODE_ERRORS);
       results.add(USED_IMPORTED_ELEMENTS);
       results.add(USED_LOCAL_ELEMENTS);
       results.add(VARIABLE_REFERENCE_ERRORS);