Skip to content

Conversation

@odersky
Copy link
Contributor

@odersky odersky commented Feb 27, 2017

Two main fixes and some cleanups:

  1. Systematically support dependent implicit methods (the test uses them)
  2. Drop unsound rule for &-simplification.
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.
The HLists test brought out the unsoundness of alias rewriting in glbs which is tackled in the last commit.
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.
}
}

object TestNonVariant {
Copy link
Contributor

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?

odersky added 4 commits March 1, 2017 08:48
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.
@odersky
Copy link
Contributor Author

odersky commented Mar 2, 2017

Something seems to be wrong with the CI on this one.

  • The status says pending
  • The CI job page says all tests failed
  • The tests log themselves all say "success"

@felixmulder: any ideas what this could be or how to fix it?

@odersky
Copy link
Contributor Author

odersky commented Mar 2, 2017

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.
@odersky
Copy link
Contributor Author

odersky commented Mar 2, 2017

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.

@odersky odersky closed this Mar 2, 2017
@felixmulder
Copy link
Contributor

felixmulder commented Mar 2, 2017 via email

@odersky
Copy link
Contributor Author

odersky commented Mar 2, 2017

Get better soon, Felix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants