fix strong mode LUB

[jmesserly]

I believe strong mode's LUB is not sound for function types (parameter types are computed via LUB).

Also we don't handle generic function types correctly:

    // The type we infer for `v` is currently `(Object) -> int`, which is wrong.
    final v = f() ? /*<T>*/(T t) => 0 : /*<T>*/(T t) => 1;
    bool f() => true;

[jmesserly]

I'm going to split out the "improve generic types" into its own bug. The soundness issue is more urgent, our upwards inference uses LUB and that will lead to incorrect conclusions. It's #25821

[jmesserly]

BTW, I added a note about handling generic function types correctly. Given two types like <U>(U) ->int and <V>(V) -> int it should construct a fresh variable F, instantiate both functions, and then run function LUB as normal (GLB on params and LUB on return type). Result would be something like: <F>(F) -> int in this example.

[leafpetersen]

There's an implied GLB on the bounds on the type parameters as well. We also need to define exactly what we mean by GLB for interface types. I suspect that the right starting (and possibly finishing point) is to take the lesser of the two types if they compare, and otherwise take bottom (with the appropriate pointwise extension for generics).

[jmesserly]

I suspect that the right starting (and possibly finishing point) is to take the lesser of the two types if they compare, and otherwise take bottom (with the appropriate pointwise extension for generics).

yeah, that's the GLB currently used for upwards inference (

sdk/pkg/analyzer/lib/src/generated/type_system.dart

Line 776 in 09a7387

if (guardedSubtype(bound.upper, newUpper, visited)) {

) -- should've factored it out properly. Doh :)

[leafpetersen]

Yes, modulo generics. We should probably eventually compute (e.g.):

  GLB(List<int>, List<String>) = List<bottom>
  GLB(List<num>, Iterable<int>) = List<int> 

instead of bottom for each of those. Basically the dual of the LUB algorithm that we also need to implement...