upwards inference for block bodied lambda returns

[jmesserly]

From @leafpetersen

A minor annoyance that comes up now and then is that we don't do upwards inference to infer the return type of block-bodied closure literals. I don't think doing so would be too difficult - we could just keep track of the LUB of the static type of all of the returned values when we visit a function body.

[munificent]

Huh, I could have sworn I filed an issue for this a while back but now I can't find it.

Either way, this was one of the biggest things I noticed when I converted a game of mine to be strong mode clean.

[leafpetersen]

I think we (or I) closed out that bug when I implemented downwards inference for block bodied functions. This does indeed catch many cases, but there are situations (especially related to generic methods) where it doesn't. So for example:

List<int> o;
o.map((x) {return x + 1;});

At the point where we're doing downwards inference, we don't have a useful type to push down into the closure. Later on when we're instantiating the generic type parameters, we want to use the type of the closure to constrain the type arguments, but here the closure return type will just be dynamic unless we infer based on the returns.

[jmesserly]

bumping to high, this is coming up in Angular code. Should be an easy fix right?

[jmesserly]

Might be worth cleaning up: _StaticTypeAnalyzer_computePropagatedReturnTypeOfFunction

It does a full tree traversal looking for return statements in the function. This is not necessary -- the relevant data could be recorded when we visit return statement as part of the original tree walk.

Fortunately, I think it only does the extra walk for local functions & lambdas.

[jmesserly]

https://codereview.chromium.org/1724543002/