Add additional strong mode inference.

pkg/analyzer/lib/src/generated/resolver.dart

Index: pkg/analyzer/lib/src/generated/resolver.dart
diff --git a/pkg/analyzer/lib/src/generated/resolver.dart b/pkg/analyzer/lib/src/generated/resolver.dart
index 6061588823e0a5aa1fd874d3d704acb081607bf2..90cefd7f370c3d9978ac20b9e79581c2afc1b9a8 100644
--- a/pkg/analyzer/lib/src/generated/resolver.dart
+++ b/pkg/analyzer/lib/src/generated/resolver.dart
@@ -13438,6 +13438,12 @@ abstract class TypeProvider {
   InterfaceType get numType;
 
   /**
+   * Return a Map mapping the method and getter names on the built-in type
+   * 'Object' to their types and return types (respectively).
+   */
+  Map<String, DartType> get objectMemberTypes;

[Brian Wilkerson, 2015/09/22 18:36:53]

I'm not thrilled with this getter for three reasons. First, it feels wrong for a
type provider to provide information about the members of a class, even though
the information is a type related to that member. Second, the map mixes two
kinds of mappings: from method names to the method's function type and from
getter names to the return type of the getter. Third, there's already a way to
accomplish the same thing.

How bad would it be to replace code like:

  typeProvider.objectMemberTypes[memberName]

with code like:

  typeProvider.objectType.element.getMethod(memberName)

or

  typeProvider.objectType.element.getGetter(memberName)

As far as I can see, we always know whether we're looking for a method or a
getter; in fact, we have to in order to know how to interpret the returned
value.

[Jennifer Messerly, 2015/09/22 18:45:52]

+1 ... I recall trying this refactoring myself at one point, though must've not
finished.

[Leaf, 2015/09/22 19:55:22]

I can take a look at changing this.  I don't think that code alone works because
I think it allows for static members and properties, which we don't want, yes? 
So the result is going to look more like

PropertyAccessorElement element =
typeProvider.objectType.element.getGetter(name);
DartType t = (element.isStatic) ? element.type : null;

Not too bad, but a bit repetitive.  (There are no static members on the object
class that I know of, but some could be added.  I think we'd also have to worry
about library private members if we didn't check for static, since the
implementation class could have library private static members, and we could be
in the same library).

[Brian Wilkerson, 2015/09/22 20:01:32]

Another option would be to add a 'getInstanceGetter' to ClassElement, or extend
the method to take an optional set of flags:

  getGetter(String name, {bool canBeStatic: true, bool canBeInstance: true})

+
+  /**
    * Return the type representing the built-in type 'Object'.
    */
   InterfaceType get objectType;
@@ -13569,6 +13575,12 @@ class TypeProviderImpl implements TypeProvider {
   InterfaceType _numType;
 
   /**
+   * The types and return types of the methods and getters (respectively) in
+   * the built-in type 'Object'.
+   */
+  Map<String, DartType> _objectMemberTypes;
+
+  /**
    * The type representing the built-in type 'Object'.
    */
   InterfaceType _objectType;
@@ -13696,6 +13708,26 @@ class TypeProviderImpl implements TypeProvider {
   InterfaceType get numType => _numType;
 
   @override
+  Map<String, DartType> get objectMemberTypes {
+    if (_objectMemberTypes == null) {
+      Map<String, DartType> map = <String, DartType>{};
+      ClassElement element = objectType.element;
+      // Add instance methods.
+      element.methods.where((method) => !method.isStatic).forEach((method) {
+        map[method.name] = method.type;
+      });
+      // Add getters.
+      element.accessors
+          .where((member) => !member.isStatic && member.isGetter)
+          .forEach((member) {
+        map[member.name] = member.type.returnType;
+      });
+      _objectMemberTypes = map;
+    }
+    return _objectMemberTypes;
+  }
+
+  @override
   InterfaceType get objectType => _objectType;
 
   @override
@@ -13755,6 +13787,7 @@ class TypeProviderImpl implements TypeProvider {
     _mapType = _getType(coreNamespace, "Map");
     _nullType = _getType(coreNamespace, "Null");
     _numType = _getType(coreNamespace, "num");
+    _objectMemberTypes = null;
     _objectType = _getType(coreNamespace, "Object");
     _stackTraceType = _getType(coreNamespace, "StackTrace");
     _streamType = _getType(asyncNamespace, "Stream");
@@ -15097,6 +15130,19 @@ class StrongTypeSystemImpl implements TypeSystem {
   @override
   DartType getLeastUpperBound(
       TypeProvider typeProvider, DartType type1, DartType type2) {
+    // TODO(vsm): The static type of a conditional should be the LUB of the

[Paul Berry, 2015/09/22 18:23:13]

Are you sure this is necessary?  I thought I fixed it in
https://codereview.chromium.org/1179343004/, and there are tests validating the
fix in pkg/analyzer/test/generated/type_system_test.dart.

(The only reason I didn't close bug 22854 is because I didn't know about it; I
discovered the bug independently).

[Leaf, 2015/09/22 18:37:28]

Right you are, thanks!  Code removed, tests still pass.

+    // then and else expressions.  The analyzer appears to compute dynamic when
+    // one or the other is the null literal.  Remove this fix once the
+    // corresponding analyzer bug is fixed:

[Jennifer Messerly, 2015/09/22 18:17:21]

I wonder if it's worth moving this fix into the analyzer generally, instead of
putting it here? That would fix the bug below. Kill two birds with one stone :)

+    // https://code.google.com/p/dart/issues/detail?id=22854
+    if (type1 != null && type2 != null) {
+      if (type1.isBottom) {
+        return type2;
+      }
+      if (type2.isBottom) {
+        return type1;
+      }
+    }
     // TODO(leafp): Implement a strong mode version of this.
     return _specTypeSystem.getLeastUpperBound(typeProvider, type1, type2);
   }