Resolve obvious deprecation warnings on bleeding edge

lib/src/codegen/js_codegen.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.
 
 import 'dart:collection' show HashSet, HashMap, SplayTreeSet;
 
 import 'package:analyzer/analyzer.dart' hide ConstantEvaluator;
 import 'package:analyzer/dart/ast/token.dart';
-import 'package:analyzer/src/generated/ast.dart' hide ConstantEvaluator;
+import 'package:analyzer/dart/element/element.dart';
+import 'package:analyzer/dart/element/visitor.dart';
+import 'package:analyzer/dart/element/type.dart';
+import 'package:analyzer/dart/ast/ast.dart' hide ConstantEvaluator;
 import 'package:analyzer/src/generated/constant.dart';
-import 'package:analyzer/src/generated/element.dart';
+//TODO(leafp): Remove deprecated dependency
+//ignore: DEPRECATED_MEMBER_USE
+import 'package:analyzer/src/generated/element.dart'
+    show DynamicElementImpl, DynamicTypeImpl, LocalVariableElementImpl;

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

There's no DynamicElement, should there be?  

We should probably just be better at keeping around a type provider here to get
rid of DynamicTypeImpl.

LocalVariableElement is an issue - we currently extend it to support our own
temps.  We may need to have a discussion about how we're going to integrate with
the ast.

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

We use this in one place:

    // type literal
    if (element is ClassElement ||
        element is DynamicElementImpl ||
        element is FunctionTypeAliasElement) {

I believe all of that can be replaced with `element is TypeDefiningElement` ...
assuming that DynamicElementImpl implements it.
That shouldn't be too hard to change. Assuming that `new LocalVariableElement`
works, we can make a synthetic one and put it in a HashSet.

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

It does.  But so does TypeParameterElement, which wouldn't currently be caught
by this check.  But that looks to me like it might be a bug?
Ok, good to know.

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

I made it that way because a type parameter defines a new type that is visible
in the scope of the generic member. If that's the wrong way to think of it we
can talk about changing it, but it would be a breaking change.

[Leaf, 2016/03/15 00:35:14]

Sorry - I meant that it might be a bug in the code generator (since at first
glance it looked to me like we might actually want this code path to fire on a
TypeParameter).  I don't immediately see any reason why TypeParameterElement
shouldn't implement TypeDefiningElement.  In some sense I suppose it doesn't
"define" a type, but it looks like TypeDefiningElement serves as the common
interface for elements which correspond to types, which a TypeParameterElement
certainly does.

[Jennifer Messerly, 2016/03/15 16:23:18]

+1, I think it's a bug in the code generator. You can probably reproduce the bug
with:

class C<T> { m() => print(T); }
main() => new C<int>().m();

 import 'package:analyzer/src/generated/engine.dart' show AnalysisContext;
 import 'package:analyzer/src/generated/resolver.dart' show TypeProvider;
 import 'package:analyzer/src/dart/ast/token.dart'
     show StringToken, Token, TokenType;
 import 'package:analyzer/src/generated/type_system.dart'
     show StrongTypeSystemImpl;
 
 import 'ast_builder.dart' show AstBuilder;
 import 'reify_coercions.dart' show CoercionReifier, Tuple2;
 
@@ skipping 468 matching lines @@
     var type = element.type;
     var name = js.string(type.name);
     var id = new JS.Identifier(type.name);
 
     // Generate a class per section 13 of the spec.
     // TODO(vsm): Generate any accompanying metadata
 
     // Create constructor and initialize index
     var constructor = new JS.Method(
         name, js.call('function(index) { this.index = index; }') as JS.Fun);
-    var fields = new List<ConstFieldElementImpl>.from(

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

There is no ConstFieldElement.  Using FieldElement here seems to work.

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

seems to still be there?
https://github.com/dart-lang/sdk/blob/3a8bc819451290e1763ab46626809d1c469c8da...

But I'm fine with FieldElement.

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

There's a ConstFieldElementImpl (which is in the private deprecated API), but
there's no corresponding public ConstFieldElement.

+    var fields = new List<FieldElement>.from(
         element.fields.where((f) => f.type == type));
 
     // Create toString() method
     var properties = new List<JS.Property>();
     for (var i = 0; i < fields.length; ++i) {
       properties.add(new JS.Property(
           js.number(i), js.string('${type.name}.${fields[i].name}')));
     }
     var nameMap = new JS.ObjectInitializer(properties, multiline: true);
     var toStringF = new JS.Method(js.string('toString'),
@@ skipping 3322 matching lines @@
 
 /// A special kind of element created by the compiler, signifying a temporary
 /// variable. These objects use instance equality, and should be shared
 /// everywhere in the tree where they are treated as the same variable.
 class TemporaryVariableElement extends LocalVariableElementImpl {
   TemporaryVariableElement.forNode(Identifier name) : super.forNode(name);
 
   int get hashCode => identityHashCode(this);
   bool operator ==(Object other) => identical(this, other);
 }