Skip to content

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

Closed
odersky opened this issue Jul 18, 2016 · 6 comments
Closed

Adding mutable.BufferLike to whitelist breaks partest #1401

odersky opened this issue Jul 18, 2016 · 6 comments
Assignees

Comments

@odersky
Copy link
Contributor

odersky commented Jul 18, 2016

Uncommenting this line

#./scala-scala/src/library/scala/collection/mutable/BufferLike.scala

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:

!! 306 - pos/compileStdLib                         [compilation failed]

# Failed test paths (this command will update checkfiles)
test/partest --update-check \
  /Users/odersky/workspace/dotty/tests/partest-generated/pos/compileStdLib

commit 9ccb47a

Any help in debugging this further would be appreciated.

@liufengyun
Copy link
Contributor

Let me take care of this.

@smarter
Copy link
Member

smarter commented Jul 18, 2016

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 tests/partest-generated/pos/compileStdLib*

@liufengyun
Copy link
Contributor

Thanks for the tip @smarter , will try as you suggested and find the root cause.

@DarkDimius
Copy link
Contributor

DarkDimius commented Jul 18, 2016

@odersky if you go to the link of failed PR
https://scala-ci.typesafe.com/job/dotty-master-validate-partest/1791/console
you can get the detailed log in the end of the output.

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 = {
               ^

@liufengyun
Copy link
Contributor

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 BufferLike.scala to the top of the white list and then run sbt "test-only -- --tests=compileStdLib".

--- a/test/dotc/scala-collections.whitelist
+++ b/test/dotc/scala-collections.whitelist
@@ -14,6 +14,8 @@
 # AnyVal is a synthesized class in Dotty, cannot be compiled from source.
 #./scala-scala/src/library/scala/AnyVal.scala

+./scala-scala/src/library/scala/collection/mutable/BufferLike.scala
+
 ./scala-scala/src/library/scala/Boolean.scala
 ./scala-scala/src/library/scala/Byte.scala
 ./scala-scala/src/library/scala/Char.scala
@@ -83,7 +85,6 @@
 ./scala-scala/src/library/scala/collection/immutable/Seq.scala
 ./scala-scala/src/library/scala/collection/mutable/IndexedSeq.scala
 ./scala-scala/src/library/scala/collection/mutable/ListBuffer.scala
-#./scala-scala/src/library/scala/collection/mutable/BufferLike.scala // works under junit, fails under partest, but can't see more info on the cause

 ./scala-scala/src/library/scala/collection/mutable/ArrayBuilder.scala

@odersky
Copy link
Contributor Author

odersky commented Jul 20, 2016

@liufengyun That's an important observation! I condensed it further to find out that compiling

Buffer.scala BufferLike.scala

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.

@liufengyun liufengyun removed their assignment Jul 20, 2016
odersky added a commit to dotty-staging/dotty that referenced this issue Jul 21, 2016
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.
@odersky odersky self-assigned this Jul 21, 2016
liufengyun added a commit that referenced this issue Jul 22, 2016
Fix #1401: Make sure all references are forwarded
nicolasstucki pushed a commit to dotty-staging/dotty that referenced this issue Jul 23, 2016
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants