Handle resolvedAst for forwarding constructors and callType on unnamed mixin applications.

tests/compiler/dart2js/serialization/test_data.dart

 // Copyright (c) 2016, 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 dart2js.serialization_test_data;
 
 const List<Test> TESTS = const <Test>[
   const Test(const {
     'main.dart': 'main() {}'
   }),
@@ skipping 220 matching lines @@
 abstract class C implements List {
   factory C([_]) = List;
 }
 main() => new C();'''
   }),
 
   const Test(const {
     'main.dart': '''
 main() => const Duration();
 ''',
-  })
+  }),
+
+  const Test(const {
+    'main.dart': '''
+import 'dart:collection';
+main() => new UnmodifiableListView(null);

[Siggi Cherem (dart-lang), 2016/05/20 21:17:53]

we should start looking into changing these tests to make it clear what they are
covering.

For example, it's not obvious to me that this test was added to cover fwd
constructors of unnamed mixin applications.

Some ideas:
(a) name each individual test, probably using the unittest framework would be
better for this. For example, you could write:

  test('fowarding constructors with unnamed mixins', () {
    checkSerialization(''' .... ''');
  });

(b) declare classes in each tests explicitly, so that the code is self contained
and doesn't depend on the current implementation of dart:core. This way we don't
loose test coverage if someone changes the implementation of
UnmodifiableListView.

I'd honestly do both (a) and (b).

[Johnni Winther, 2016/05/23 08:42:36]

(a) Naming, yes. The unittest package, no. (Last time I looked it interleaved
execution of asynchronous tests which makes the output incomprehensible!)

(b) The problem here is the combination of a serialized named mixin application
and a nonserialized use; i.e. it'll require a better rewrite of the test
infrastructure so I'll leave for a later CL.

[Siggi Cherem (dart-lang), 2016/05/23 16:25:10]

Let's give it another try... unittest should support async tests now: As long as
the test function returns a future, the unittest package will not execute any
subsequent test until the future completes.

+''',
+  }),
 ];
 
 class Test {
   final Map sourceFiles;
   final int expectedErrorCount;
   final int expectedWarningCount;
   final int expectedHintCount;
   final int expectedInfoCount;
 
   const Test(this.sourceFiles, {
     this.expectedErrorCount: 0,
     this.expectedWarningCount: 0,
     this.expectedHintCount: 0,
     this.expectedInfoCount: 0});
 }