Strong mode checker integration

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

 // Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 library analysis_server.src.status.get_handler;
 
 import 'dart:async';
 import 'dart:collection';
 import 'dart:convert';
 import 'dart:io';
@@ skipping 253 matching lines @@
       return unit;
     }
     unit = entry.getValue(RESOLVED_UNIT7);
     if (unit != null) {
       return unit;
     }
     unit = entry.getValue(RESOLVED_UNIT8);
     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);
   }
 
   /**
    * Return a list of the result descriptors whose state should be displayed for
    * the given cache [entry].
    */
   List<ResultDescriptor> _getExpectedResults(CacheEntry entry) {
     AnalysisTarget target = entry.target;
     Set<ResultDescriptor> results = entry.nonInvalidResults.toSet();
@@ skipping 46 matching lines @@
       results.add(RESOLVE_TYPE_NAMES_ERRORS);
       results.add(RESOLVE_UNIT_ERRORS);
       results.add(RESOLVED_UNIT1);
       results.add(RESOLVED_UNIT2);
       results.add(RESOLVED_UNIT3);
       results.add(RESOLVED_UNIT4);
       results.add(RESOLVED_UNIT5);
       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);
       results.add(VERIFY_ERRORS);
     } else if (target is ConstantEvaluationTarget) {
       results.add(CONSTANT_DEPENDENCIES);
       results.add(CONSTANT_VALUE);
       if (target is VariableElement) {
         results.add(INFERABLE_STATIC_VARIABLE_DEPENDENCIES);
         results.add(INFERRED_STATIC_VARIABLE);
@@ skipping 1533 matching lines @@
    */
   static String makeLink(
       String path, Map<String, String> params, String innerHtml,
       [bool hasError = false]) {
     Uri uri = new Uri(path: path, queryParameters: params);
     String href = HTML_ESCAPE.convert(uri.toString());
     String classAttribute = hasError ? ' class="error"' : '';
     return '<a href="$href"$classAttribute>$innerHtml</a>';
   }
 }