-
Notifications
You must be signed in to change notification settings - Fork 1.1k
More tests #1006
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
More tests #1006
Conversation
As the comment explains, this is not sound.
The fix solves two cases where we had a deep subtype before.
Since And/Or type themselves are parameterless, their the union and intersection of hgiher-kinded types has to be treated specially: The types have to be pulled under a common lambda.
If splitProjections is set, it is more efficient that way.
All pos tests up to 3999 have been triaged. One new test in pending.
Symbols can appear in patterns, so inserting an `apply` is wrong.
revios fix crashed for nullary functions
In a situation like List <: [X] -> <: GenTraversable[X] We have to ask whether the rhs contains the instantiated lhs, not whether it is a supertype.
This one is based on #1001, which should go in first. |
/rebuild |
Something weird is going on with constraints, in: class A {
def f[CC[X] <: Traversable[X]](x: CC[Int]): CC[Int] = x
f(1 to 5)
} we get: [info] added constraint CC <: [+X0] -> scala.collection.immutable.IndexedSeq[X0] to
[info] Constraint(
[info] uninstVars = CC;
[info] constrained types =
[info] [CC <: [X0] -> <: scala.collection.Traversable[X0]](x: CC[Int])CC[Int]
[info] bounds =
[info] CC = [+X0] -> scala.collection.immutable.IndexedSeq[X0]
[info] ordering =
[info] ) = true
[error] [log frontend] ==> adapting intWrapper(1).to of type ((end: Int)scala.collection.immutable.Range.Inclusive)(scala.runtime.RichInt#to) to FunProto(5):??
[error] [log frontend] <== adapting intWrapper(1).to of type ((end: Int)scala.collection.immutable.Range.Inclusive)(scala.runtime.RichInt#to) to FunProto(5):? = intWrapper(1).to
[error] [log frontend] <== adapting intWrapper(1).to of type <overloaded scala.runtime.RichInt#to> to FunProto(5):? = intWrapper(1).to
[error] [log frontend] <== typing 1.to = intWrapper(1).to
[error] [log frontend] ==> adapting 5 of type Int(5) to Int?
[error] [log frontend] <== adapting 5 of type Int(5) to Int = 5
[error] [log frontend] ==> adapting intWrapper(1).to(5) of type scala.collection.immutable.Range.Inclusive to CC[Int]?
[error] [log frontend] <== adapting intWrapper(1).to(5) of type scala.collection.immutable.Range.Inclusive to CC[Int] = intWrapper(1).to(5)
[error] [log frontend] ==> adapting this.f[CC](intWrapper(1).to(5)) of type CC[Int] to ??
[info] interpolate undet vars in CC[Int], pos = [71..72..80], mode = Mode(ImplicitsEnabled), undets = ArrayBuffer(CC@[71..72])
[info] qualifying undet vars: ArrayBuffer(TypeVar(PolyParam(CC)) / CC), constraint: Constraint(
[info] uninstVars = CC;
[info] constrained types =
[info] [CC <: [X0] -> <: scala.collection.Traversable[X0]](x: CC[Int])CC[Int]
[info] bounds =
[info] CC <: [X0] -> <: scala.collection.Traversable[X0]
[info] ordering =
[info] )
[info] interpolate covariant CC in CC[Int]
[info] approx CC, from below = true, bound = Nothing, inst = Nothing
[info] instantiating CC with Nothing Notice that we correctly have |
Where did that test come from? The example compiles OK for me (?) @smarter @DarkDimius I cannot make sense of the test failures of this commit. It says something about compilation of pos/printing_v1fails, but I have no idea what that is. Can you help? |
I took
Not sure what the problem is either, I suspect it might be another kind of random bug that disappear when we rebuild. |
/rebuild |
LGTM since the issues I encountered are not specific to this PR, I'll investigate them separately |
Lots of new tests and some fixes. Review by @smarter