-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Adding mutable.BufferLike to whitelist breaks partest #1401
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
Comments
Let me take care of this. |
Unfortunately jenkins is not configured to save all of this currently but you could run it locally and see if some logs are saved in |
Thanks for the tip @smarter , will try as you suggested and find the root cause. |
@odersky if you go to the link of failed PR The reported error message: ^
/home/jenkins/workspace/dotty-master-validate-partest@2/tests/partest-generated/pos/compileStdLib/BufferLike.scala:62: error: illegal inheritance: self type This & scala.collection.mutable.BufferLike[A, This] of trait BufferLike does not conform to self type scala.collection.generic.Subtractable[A, This & scala.collection.mutable.Buffer[A]] of parent trait Subtractable
trait BufferLike[A, +This <: BufferLike[A, This] with Buffer[A]]
^
/home/jenkins/workspace/dotty-master-validate-partest@2/tests/partest-generated/pos/compileStdLib/BufferLike.scala:236: error: overriding method - in trait Subtractable of type (elem: A)This & scala.collection.mutable.Buffer[A];
method - of type (elem: A)This has incompatible type
override def -(elem: A): This = clone() -= elem
^
/home/jenkins/workspace/dotty-master-validate-partest@2/tests/partest-generated/pos/compileStdLib/BufferLike.scala:248: error: overriding method - in trait Subtractable of type (elem1: A, elem2: A, elems: A*)This & scala.collection.mutable.Buffer[A];
method - of type (elem1: A, elem2: A, elems: A*)This has incompatible type
override def -(elem1: A, elem2: A, elems: A*): This = clone() -= elem1 -= elem2 --= elems
^
/home/jenkins/workspace/dotty-master-validate-partest@2/tests/partest-generated/pos/compileStdLib/BufferLike.scala:258: error: overriding method -- in trait Subtractable of type (xs: scala.collection.GenTraversableOnce[A])This & scala.collection.mutable.Buffer[A];
method -- of type (xs: scala.collection.GenTraversableOnce[A])This has incompatible type
override def --(xs: GenTraversableOnce[A]): This = clone() --= xs.seq
^
/home/jenkins/workspace/dotty-master-validate-partest@2/tests/partest-generated/pos/compileStdLib/BufferLike.scala:264: error: overriding method clone in trait Cloneable of type ()scala.collection.mutable.Buffer[A] & This;
method clone of type ()This has incompatible type
override def clone(): This = {
^ |
The problem is related to the order of source files for compilation. In JUnit tests, the source files are ordered as they are specified in the whitelist. But in partest, all sources files are in the same folder, they are ordered by file name. We can reproduce the compilation error by moving
|
@liufengyun That's an important observation! I condensed it further to find out that compiling
works, but reversing the order has the error. I tracked it down to differences in the way type parameters are bound in subclasses. In the OK scenario, Buffer contains several bindings for superclass parameters that it lacks in the error scenario. Will dig further. |
Faced with recursive dependencies through self types, we might have to apply `normalizeToClassRefs` to a class P with a parent that is not yet initialized (witnessed by P's parents being Nil). In that case we should still execute forwardRefs on P, but we have to wait in a suspension until P is initialized. This avoids the problem raised in scala#1401. I am still not quite sure why forwardRefs is needed, but it seems that asSeenFrom alone is not enough to track the dependencies in this case.
Fix #1401: Make sure all references are forwarded
Faced with recursive dependencies through self types, we might have to apply `normalizeToClassRefs` to a class P with a parent that is not yet initialized (witnessed by P's parents being Nil). In that case we should still execute forwardRefs on P, but we have to wait in a suspension until P is initialized. This avoids the problem raised in scala#1401. I am still not quite sure why forwardRefs is needed, but it seems that asSeenFrom alone is not enough to track the dependencies in this case.
Uncommenting this line
in scala-collections-whitelist breaks partest, when run with all the other test but succeeds when
compileStdLib
is run as the only test. Unfortunately, the only debug info I can see is this:commit 9ccb47a
Any help in debugging this further would be appreciated.
The text was updated successfully, but these errors were encountered: