Implement new flatten specification.

Implement new flatten specification.

BUG=http://dartbug.com/22921
R=karlklose@google.com

Committed: https://code.google.com/p/dart/source/detail?r=44659

[Johnni Winther, 2015-03-24 10:22:07]

johnniwinther@google.com changed reviewers:
+ karlklose@google.com

[karlklose, 2015-03-24 10:27:44]

LGTM.

https://codereview.chromium.org/1035443002/diff/1/pkg/compiler/lib/src/dart_t...
File pkg/compiler/lib/src/dart_types.dart (right):

https://codereview.chromium.org/1035443002/diff/1/pkg/compiler/lib/src/dart_t...
pkg/compiler/lib/src/dart_types.dart:1250: return
futureType.typeArguments.first;
You could use 'single' instead of 'first'. OTOH GenericType already checks the
number of type arguments, so it is not really necessary.

[Johnni Winther, 2015-03-24 11:24:04]

https://codereview.chromium.org/1035443002/diff/1/pkg/compiler/lib/src/dart_t...
File pkg/compiler/lib/src/dart_types.dart (right):

https://codereview.chromium.org/1035443002/diff/1/pkg/compiler/lib/src/dart_t...
pkg/compiler/lib/src/dart_types.dart:1250: return
futureType.typeArguments.first;
On 2015/03/24 10:27:43, karlklose wrote:
> You could use 'single' instead of 'first'. OTOH GenericType already checks the
> number of type arguments, so it is not really necessary.

Done. Livrem og seler.

[Johnni Winther, 2015-03-24 11:29:07]

Committed patchset #2 (id:20001) manually as 44659 (presubmit successful).

[Paul Berry, 2015-03-25 15:22:25]

paulberry@google.com changed reviewers:
+ paulberry@google.com

[Paul Berry, 2015-03-25 15:22:25]

https://codereview.chromium.org/1035443002/diff/20001/pkg/compiler/lib/src/da...
File pkg/compiler/lib/src/dart_types.dart (right):

https://codereview.chromium.org/1035443002/diff/20001/pkg/compiler/lib/src/da...
pkg/compiler/lib/src/dart_types.dart:1241: DartType flatten(DartType type) {
There are two corner cases I ran into in the analyzer implementation that don't
seem to be addressed here.  If T != Future<S> but T <: Future, it's possible for
there to be multiple type arguments to Future appearing in the class hierarchy. 
When this happens, there will either be:

1. a single type S that is at least as specific as all the others (i.e. the
"most specific" type argument to future), in which case, that should be the
result of flatten().  Or:

2. no type S that is at least as specific as all the others, in which case I
believe flatten(T) should be T.

For example, assume the following classes exist:
class Base
class Derived1 extends Base
class Derived2 extends Base
class A extends Future<Derived1> implements Future<Base>
class B extends Future<Base> implements Future<Derived1>
class C extends Future<Derived1> implements Future<Derived2>
class D extends Future<Derived2> implements Future<Derived1>

Then:
- flatten(A) = flatten(B) = Derived1, since Derived1 is more specific than Base
(case 1).
- flatten(C) = C and flatten(D) = D, since neither Derived1 nor Derived2 is more
specific than the other.

The general algorithm for finding the "most specific" type out of a set (if it
exists) turned out to be unexpectedly tricky.  You can see my implementation
around line 1855 of
https://codereview.chromium.org/1023903002/diff/1/pkg/analyzer/lib/src/genera...
(the _findMostSpecificType function).