Resolve obvious deprecation warnings on bleeding edge

lib/src/utils.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.
 
 /// Holds a couple utility functions used at various places in the system.
 
 import 'dart:io';
 import 'package:path/path.dart' as path;
-import 'package:analyzer/src/generated/ast.dart'
+import 'package:analyzer/dart/ast/ast.dart'
     show
         ImportDirective,
         ExportDirective,
         PartDirective,
         CompilationUnit,
         Identifier,
         AnnotatedNode,
         AstNode,
         Expression,
         SimpleIdentifier,
         MethodInvocation;
+import 'package:analyzer/dart/element/element.dart';
+import 'package:analyzer/dart/element/type.dart';
 import 'package:analyzer/src/generated/constant.dart' show DartObject;
-import 'package:analyzer/src/generated/element.dart';
+//TODO(leafp): Remove deprecated dependency
+//ignore: DEPRECATED_MEMBER_USE

[Jennifer Messerly, 2016/03/14 23:12:42]

oh, I was confused because it didn't look deprecated:
https://github.com/dart-lang/sdk/blob/3a8bc819451290e1763ab46626809d1c469c8da...

I guess you're saying it's non-public. Yeah, it seems good to move off the
non-public APIs if possible

[Leaf, 2016/03/14 23:58:42]

src/generated/element.dart is deprecated.  I can move us over to
src/dart/element/element.dart, and will do so if we decide we want to keep
reaching in, but I wanted to first call out the places where we are reaching our
tendrils into the analyzer internals.

+import 'package:analyzer/src/generated/element.dart' show DynamicTypeImpl;
 import 'package:analyzer/src/generated/engine.dart' show AnalysisContext;
 import 'package:analyzer/src/generated/error.dart' show ErrorCode;
 import 'package:analyzer/src/task/dart.dart' show ParseDartTask;
 import 'package:analyzer/src/generated/resolver.dart' show TypeProvider;
 import 'package:analyzer/src/generated/source.dart' show LineInfo, Source;
 import 'package:analyzer/analyzer.dart' show parseDirectives;
 import 'package:crypto/crypto.dart' show CryptoUtils, MD5;
 import 'package:source_span/source_span.dart';
 
 import 'codegen/js_names.dart' show invalidVariableName;
@@ skipping 433 matching lines @@
     new File(source).copySync(destination);
   }
 
   void writeAsStringSync(String file, String contents) {
     _ensureParentExists(file);
     new File(file).writeAsStringSync(contents);
   }
 }
 
 DartType getStaticType(Expression e) =>
     e.staticType ?? DynamicTypeImpl.instance;

[Leaf, 2016/03/14 22:47:55]

We rely in places on being able to just get the canonincal instance of
DynamicType, which is not available from the DynamicType interface.  Probably we
should just be better about passing around a type provider.

[Jennifer Messerly, 2016/03/14 23:12:42]

Is there a reason? I'd prefer to use the well known `dynamic`. It's painful to
pass around TypeProviders... (and TypeSystems ...)  Better, IMO, would be to
offer an easy way to get it.

Funny enough, you could do it already with something terrible like:

    e.getAncestor((a) => a is
CompilationUnit).element.library.context.typeProvider

... ouch :)

Brainstorming here a bit ... the problem really is filling in `null`. That's not
supposed to happen after resolution, AFAIK. (see
StaticTypeAnalyzer._recordStaticType), so this might be a bug we've been working
around unknowingly.

[Leaf, 2016/03/14 23:58:42]

I think it's just a question about the analyzer API design - should the public
API commit to the canonical instance being available statically, or does it want
to reserve the right to implement it in some other way?

We should probably look in and see if we actually need this function at some
point.  Added a TODO.

[Brian Wilkerson, 2016/03/15 00:14:16]

That does sound suspicious, and we should look into it. I found another case
earlier today, where VariableElement (IIRC) is documented as being able to have
a `null` type when one isn't declared. That sounds wrong to me too.

 
 // TODO(leafp) Factor this out or use an existing library
 class Tuple2<T0, T1> {
   final T0 e0;
   final T1 e1;
   Tuple2(this.e0, this.e1);
 }