- Notifications
You must be signed in to change notification settings - Fork 1.1k
Fixes related to HList type inference #2034
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
Conversation
If an applied type has a refinement, it was printed before as one large refinement type including the type parameter bindings.
No reason why we should not - normalize handles implicit methods just fine. This fixes type errors in test HLists.scala.
We approximate dependencies to parameters by Wildcards. This was already done in one place, is now done in other places as well, instead of doing nothing for dependent methods.
We previously tried to force S1 and S2 be the same type when encountering a lub like `T1 { A = S1 } & T2 { A = S2 }`. The comments in this commit explain why this is unsound, so this rewrite is now made subject to a new config option, which is off by default. I verified that the new behavior does not affect the performance of the junit tests. These now compile with the changes to dependent methods, except for one which is invalid under dotty.
Variance changes quite a few things for type inference, so it's good to check a non-variant version as well.
tests/run/HLists-nonvariant.scala Outdated
| } | ||
| } | ||
| | ||
| object TestNonVariant { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These objects (Test and TestNonVariant) are identical. Is it intentional?
Need to use fresh PolyParams instead of WildcardTypes if constraint is committable.
Turned out hmaps.scala requires the arg alignment to compile. So we have our first counterexample that we cannot drop this hack. Now it is made safe in the sense that no constraints get lost anymore.
I believe this worked only accidentally because we matched more things with wildcards which turned out to be flawed. The test errors show some funky _#_ types, so not sure whether the tests are still valid or not. Moved back to pending awaiting further resolution.
| Something seems to be wrong with the CI on this one.
@felixmulder: any ideas what this could be or how to fix it? |
| Also, I noticed that commits before the last one all get a tick, even if they were not tested themselves. That risks being misleading. |
Type inference tends to take quite different paths for non-variant and variant data structures. Since, non-variant hmap has already exposed quite a few problems, it's good to test it also in the covariant case.
| I pushed a new commit, but now CI won't even start on this one. It seems the previous zombie run prevents the CI from doing anything further here. Will try with a new PR. |
| The bot currently sets the status of each commit that it has checked the CLA for. I could change it to set a status (failed) only if the user hasn't signed the CLA...But this won't let us know if the bot is really working... Yes, kill the PR, probably best...I'm currently in bed with a fever. Will check more on it tomorrow. On Thu, Mar 2, 2017, 18:12 odersky <notifications@github.com> wrote: Also, I noticed that commits before the last one all get a tick, even if they were not tested themselves. That risks being misleading. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2034 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABdYwb0MNImHsyvYgUK6HqaXgyo2_wexks5rhogDgaJpZM4MM8E8> . |
| Get better soon, Felix! |
Two main fixes and some cleanups: