Static type of "(x) => null" is computed as "(dynamic) => <bottom>"

[vsmenon]

This should be (dynamic) => dynamic per spec as I understand it. Not sure if this is the analyzer or our mods to it.

@leafpetersen @bwilkerson @sigmundch

[jmesserly]

@vsmenon does this still reproduce?

[vsmenon]

Yes, here's a repro:

void foo() {
  var f = (x) => null;
  f = (x) => "hello";
}

generates:

warning: [UninferredClosure] (x) => "hello" ((dynamic) → String) will need runtime check to cast to type (dynamic) → <bottom>

[jmesserly]

It looks like this is our inference. In some cases, like local var inference, we're careful not to accept bottom type. However this logic doesn't kick in consistently.

I'm guessing lambda expression return type and return statements have this problem. Upwards generic methods I think is okay, as we reject "bottom", which can happen sometimes naturally as a result of computing the lower/upper bounds. (edit: can confirm that upwards inference explicitly rejects bottom, if (inferredTypes[i].isBottom || ... ) { inferredTypes[i] = DynamicTypeImpl.instance; ...)

[jmesserly]

BTW, bottom comes into play as the type of null, per the spec.

[jmesserly]

haven't figured this out entirely, but my guess is that the static type () -> ⊥ for () => null comes from the spec type system. Probably our inference on function expressions should fix that up, in strong mode. Given that we have downward inference, I don't think we'll need to preserve that type as ⊥ (one possibility is to fix this for null itself, since the literal itself can be typed as anything from its context, not sure the spec type system treatment gets us anything. But we could also just fix it at the function expression level, since we already guard against ⊥ in our other inference.)

[jmesserly]

https://codereview.chromium.org/1649523002/