-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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 |
BTW, I added a note about handling generic function types correctly. Given two types like |
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). |
yeah, that's the GLB currently used for upwards inference (
|
Yes, modulo generics. We should probably eventually compute (e.g.):
instead of |
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. |
Generics are covered by #25821 so I think we can close this. Yay :) |
Ah, cool. Didn't realize there was a separate bug for that. :) |
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 text was updated successfully, but these errors were encountered: