Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix strong mode LUB #25802

Closed
jmesserly opened this issue Feb 17, 2016 · 8 comments
Closed

fix strong mode LUB #25802

jmesserly opened this issue Feb 17, 2016 · 8 comments
Assignees
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@jmesserly
Copy link

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 jmesserly added Type-Defect P1 A high priority bug; for example, a single project is unusable or has many test failures area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Feb 17, 2016
@munificent munificent mentioned this issue Feb 18, 2016
35 tasks
@jmesserly
Copy link
Author

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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 (

if (guardedSubtype(bound.upper, newUpper, visited)) {
) -- should've factored it out properly. Doh :)

@leafpetersen
Copy link
Member

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...

@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed Type-Defect labels Mar 1, 2016
@munificent
Copy link
Member

Made some more progress on this here: https://codereview.chromium.org/1807213005/

Still need to do generics, but LUB for function types should be correct now.

@jmesserly
Copy link
Author

Generics are covered by #25821 so I think we can close this. Yay :)

@munificent
Copy link
Member

Ah, cool. Didn't realize there was a separate bug for that. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. P1 A high priority bug; for example, a single project is unusable or has many test failures type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

4 participants