Some preliminary support for quasi-generics

Some preliminary support for quasi-generics

This just expands John's earlier hack on min/max.  No downward
inference, etc, but it captures some simple cases.  Worthwhile?

Testing whether this makes much of a difference on our larger code bases.

R=jmesserly@google.com, leafp@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/4921c78b68037c5b25a8e2ed6a8d7c484d5f52bf

[vsm, 2015-08-27 23:01:59]

vsm@google.com changed reviewers:
+ jmesserly@google.com, leafp@google.com

[Leaf, 2015-08-28 01:05:38]

This basically lgtm.  One hesitation is that you are doing bottom up inference. 
I would eventually like to do both bottom up inference and top down inference
for generic methods, but my initial thinking was to do top down inference (in
part because it's less of a slam dunk that we want to do bottom up inference for
mutable generic data structures, e.g. var x = [3]).  Once we hand out this
candy, might be a little hard to take it away, even if only temporarily.  But
maybe that just says that I should implement both from the start, again, at
least for generic methods which don't suffer from the mutability issue.

https://codereview.chromium.org/1317933005/diff/20001/lib/src/checker/resolve...
File lib/src/checker/resolver.dart (right):

https://codereview.chromium.org/1317933005/diff/20001/lib/src/checker/resolve...
lib/src/checker/resolver.dart:629: (tx is FunctionType &&
!tx.returnType.isDynamic)
Why are you checking for dynamic here, and not elsewhere?

Also, you may need to deal with the fact that these functions can return a
future or a value.  I think this code will get one of the two wrong - I think
the former:

Future<int> f(...) => ...
future.then(f); // This will be inferred as Future<Future<int>>?

EDITED to add: this is probably the point of your TODO?

[vsm, 2015-08-28 15:48:50]

Thanks - if you've got some time, let's chat about this today.  I'm collecting
some data in the wild.

https://codereview.chromium.org/1317933005/diff/20001/lib/src/checker/resolve...
File lib/src/checker/resolver.dart (right):

https://codereview.chromium.org/1317933005/diff/20001/lib/src/checker/resolve...
lib/src/checker/resolver.dart:620: ?
_typeProvider.iterableType.substitute4([tx.returnType])
Hmm - rethinking this ...  If my target type (statically) is:

class Foo<T> extends Iterable<T> {
  ...
  List map(Function f) {}
}

and I have:

  target.map((x) => x.toString())

I'll infer Iterable<String> instead of List<dynamic>.

[Jennifer Messerly, 2015-08-28 21:49:07]

looks like SDK failed to generate?
otherwise LGTM!

https://codereview.chromium.org/1317933005/diff/40001/lib/src/checker/resolve...
File lib/src/checker/resolver.dart (right):

https://codereview.chromium.org/1317933005/diff/40001/lib/src/checker/resolve...
lib/src/checker/resolver.dart:746: // TODO(vsm): If the inferred type is not a
subtype, should we use a GLB instead?
long line?

[vsm, 2015-08-28 21:55:20]

On 2015/08/28 21:49:07, John Messerly wrote:
> looks like SDK failed to generate?

Doh!  Thanks, I uploaded too early.  Looking at may be reusing Leaf's matchTypes
in lieu of GLB below...

> otherwise LGTM!
> 
>
https://codereview.chromium.org/1317933005/diff/40001/lib/src/checker/resolve...
> File lib/src/checker/resolver.dart (right):
> 
>
https://codereview.chromium.org/1317933005/diff/40001/lib/src/checker/resolve...
> lib/src/checker/resolver.dart:746: // TODO(vsm): If the inferred type is not a
> subtype, should we use a GLB instead?
> long line?

[vsm, 2015-08-31 16:56:56]

Committed patchset #4 (id:50001) manually as
4921c78b68037c5b25a8e2ed6a8d7c484d5f52bf (presubmit successful).