fix #214, check type of inferred initializing formal with default value

lib/src/checker/resolver.dart

 // Copyright (c) 2015, 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.
 
 /// Encapsulates how to invoke the analyzer resolver and overrides how it
 /// computes types on expressions to use our restricted set of types.
 library dev_compiler.src.checker.resolver;
 
 import 'package:analyzer/analyzer.dart';
 import 'package:analyzer/src/generated/ast.dart';
@@ skipping 312 matching lines @@
     var extractor = new _VarExtractor();
     initializer.accept(extractor);
     return extractor.elements;
   }
 }
 
 /// Overrides the default [ResolverVisitor] to support type inference in
 /// [LibraryResolverWithInference] above.
 ///
 /// Before inference, this visitor is used to resolve top-levels, classes, and
-/// fields, but nothing withihn method bodies. After inference, this visitor is
+/// fields, but nothing within method bodies. After inference, this visitor is
 /// used again to step into method bodies and complete resolution as a second
 /// phase.
 class RestrictedResolverVisitor extends ResolverVisitor {
   final TypeProvider _typeProvider;
 
   /// Whether to skip resolution within method bodies.
   bool skipMethodBodies = true;
 
   /// State of the resolver at the point a field or variable was declared.
   final _stateAtDeclaration = <AstNode, _ResolverState>{};
@@ skipping 102 matching lines @@
   @override
   Object visitConstructorDeclaration(ConstructorDeclaration node) {
     if (skipMethodBodies) {
       node.accept(elementResolver);
       node.accept(typeAnalyzer);
       return null;
     } else {
       return super.visitConstructorDeclaration(node);
     }
   }
+
+  @override
+  visitFieldFormalParameter(FieldFormalParameter node) {
+    // Ensure the field formal parameter's type is updated after inference.
+    // Normally this happens during TypeResolver, but that's before we've done
+    // inference on the field type.

[Jennifer Messerly, 2015/06/10 18:22:19]

Is this running at the right time?

In theory, nothing should depend on the parameter type, right? Except verifying:
1. its use inside the method
2. that calls were passing the correct type

Both of those are handled by our very own CodeChecker.

At least, that's the theory I'm operating under here.

Everything seems to work if I move this code below into StaticTypeAnalyzer, but
it seemed better to do as early as possible, since the
FieldFormalParameterElement is born with the wrong type to begin with.

[Siggi Cherem (dart-lang), 2015/06/10 18:28:30]

sgtm. not sure when analyzer does it, but if element.type here is already
incorrect, it seems appropriate to fix it early.

+    var element = node.element;
+    if (element is FieldFormalParameterElement) {
+      if (element.type.isDynamic) {
+        element.type = element.field.type;
+      }
+    }
+    super.visitFieldFormalParameter(node);
+  }
 }
 
 /// Internal state of the resolver, stored so we can reanalyze portions of the
 /// AST quickly, without recomputing everything from the top.
 class _ResolverState {
   final TypePromotionManager_TypePromoteScope promotionScope;
   final TypeOverrideManager_TypeOverrideScope overrideScope;
   final Scope nameScope;
 
   _ResolverState(ResolverVisitor visitor)
@@ skipping 206 matching lines @@
     }
   }
 
   // Review note: no longer need to override visitFunctionExpression, this is
   // handled by the analyzer internally.
   // TODO(vsm): in visitbinaryExpression: check computeStaticReturnType result?
   // TODO(vsm): in visitFunctionDeclaration: Should we ever use the expression
   // type in a (...) => expr or just the written type?
 
 }