Skip to content
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

Spurious errors when compiling the Scala library, depending on the file order #5644

Closed
scabug opened this issue Apr 3, 2012 · 16 comments
Closed
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Apr 3, 2012

The compiler crashes with the following error in the backend (an overloaded type reaches backend):

error: Unknown type: (x: Object, y: Object)Boolean <and> (x$1: Object)Boolean, (x: Object, y: Object)Boolean <and> (x$1: Object)Boolean [class scala.reflect.internal.Types$OverloadedType, class scala.reflect.internal.Types$OverloadedType] TypeRef? false
error: 
     while compiling:  /Users/dragos/workspace/git/scala/src/library/scala/xml/pull/XMLEventReader.scala
       current phase:  jvm
     library version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
    compiler version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
  reconstructed args:  -classpath lib/fjbg.jar:lib/ant/ant.jar:lib/msil.jar -verbose -d /tmp

uncaught exception during compilation: scala.reflect.internal.FatalError
error: scala.reflect.internal.FatalError: 
     while compiling:  /Users/dragos/workspace/git/scala/src/library/scala/xml/pull/XMLEventReader.scala
       current phase:  jvm
     library version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
    compiler version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
  reconstructed args:  -classpath lib/fjbg.jar:lib/ant/ant.jar:lib/msil.jar -verbose -d /tmp

Unknown type: (x: Object, y: Object)Boolean <and> (x$1: Object)Boolean, (x: Object, y: Object)Boolean <and> (x$1: Object)Boolean [class scala.reflect.internal.Types$OverloadedType, class scala.reflect.internal.Types$OverloadedType] TypeRef? false
	at scala.reflect.internal.SymbolTable.abort(SymbolTable.scala:38)
	at scala.tools.nsc.Global.abort(Global.scala:191)
	at scala.tools.nsc.backend.icode.TypeKinds$class.toTypeKind(TypeKinds.scala:397)
	at scala.tools.nsc.backend.icode.ICodes.toTypeKind(ICodes.scala:25)
	at scala.tools.nsc.backend.jvm.GenJVMUtil$BytecodeUtil$class.javaType(GenJVMUtil.scala:100)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaType(GenJVM.scala:183)
	at scala.tools.nsc.backend.jvm.GenJVMUtil$BytecodeUtil$class.javaType(GenJVMUtil.scala:109)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaType(GenJVM.scala:183)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genCallMethod$1(GenJVM.scala:1270)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genBlock$1$1.apply(GenJVM.scala:1393)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genBlock$1$1.apply(GenJVM.scala:1313)
	at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:34)
	at scala.collection.mutable.ArrayOps.foreach(ArrayOps.scala:38)
	at scala.tools.nsc.backend.icode.BasicBlocks$BasicBlock.foreach(BasicBlocks.scala:184)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genBlock$1(GenJVM.scala:1313)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genBlocks$1(GenJVM.scala:1181)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genCode(GenJVM.scala:1784)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genMethod(GenJVM.scala:940)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genClass$3.apply(GenJVM.scala:465)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genClass$3.apply(GenJVM.scala:465)
	at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
	at scala.collection.immutable.List.foreach(List.scala:77)
	at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genClass(GenJVM.scala:465)
	at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$3.apply(GenJVM.scala:165)
	at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$3.apply(GenJVM.scala:164)
	at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
	at scala.collection.immutable.List.foreach(List.scala:77)
	at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase.run(GenJVM.scala:164)
	at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1307)
	at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1280)
	at scala.tools.nsc.Global$Run.compileSources(Global.scala:1274)
	at scala.tools.nsc.Global$Run.compile(Global.scala:1404)
	at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
	at scala.tools.nsc.Main$.doCompile(Main.scala:81)
	at scala.tools.nsc.Driver.process(Driver.scala:52)
	at scala.tools.nsc.Driver.main(Driver.scala:65)
	at scala.tools.nsc.Main.main(Main.scala)

error: fatal error: 
     while compiling:  /Users/dragos/workspace/git/scala/src/library/scala/xml/pull/XMLEventReader.scala
       current phase:  jvm
     library version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
    compiler version:  version 2.10.0-SNAPSHOT-20120319-00000000-78c15103d5
  reconstructed args:  -classpath lib/fjbg.jar:lib/ant/ant.jar:lib/msil.jar -verbose -d /tmp

The error appears and goes away depending on the order in which files are compiled. I can reproduce it by compiling together everything under 'src/library', in the order listed in the attached file. Run it with
scalac -d /tmp @sources-lib.

Sorry I cannot narrow it down more than this, but I hope it's enough to get someone to look at it. It's a blocker for anyone trying to build the Scala library in the IDE (or it may not, depending on the order in which it happens to build those files).

@scabug
Copy link
Author

scabug commented Apr 3, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5644?orig=1
Reporter: @dragos
Attachments:

  • sources-lib (created on Apr 3, 2012 1:35:38 PM UTC, 62496 bytes)

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
You're right, that was interesting to minimize.

As long as one file is BoxesRunTime.java, the second can be all kinds of things and it will crash. And in either order; so it's not exactly an order-of-arguments bug, just something which is sensitive to the order things unroll.

scalac src/library/scala/runtime/BoxesRunTime.java src/library/scala/collection/Iterator.scala

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@dragos said:
Great job! These things are hell to reproduce. Thanks a lot for looking into it.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
This can be the file to go with BoxesRunTime:

trait Foo { def contains(elem: Any) = List(1) exists(_ == elem) }

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
The funny thing is, only a week or two ago I ran a script for a couple of days which did nothing but grab random permutations of files in a random order from trunk and try to compile them, looking for crashes. That's how I minimized #5604. But I unwisely did not include java files.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@gkossakowski said:
Wow! I stumbled upon this bug a few months ago myself but I felt there's something broken with my setup and I gave up on investigating further. I can see this being super hard to minimize. Bravo!

  • I couldn't believe that order of files when building library matters and nobody has detected this apart from me...

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
This is a regression from 2.9 ; are you sure about a couple months ago? I have some more recent changes in mind, but I should cast a wider net if that's the case.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
My latest build before I stopped collecting them (it really hurts in spots like this) the bug is not there, so it's sometime since Nov 29.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
It's not in M2 either, which brings me back to my suspect, the work that was done with partial functions, because I know it was generating stuff during uncurry and I can remember running into this difficulty before with overloaded methods after typer.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@gkossakowski said:
Well, I saw similar compiler crash around September. It's very likely we talk about two different issues, here.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
I found it. Will check in soon.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@dragos said:
What a team! (Paul does the work, and we cheer on the side!) Thanks a lot.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
Just glad to be on the field.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@dragos said:
It's great to have you on the team.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
Stop, you'll make me blush. Glad to be on your team too.

@scabug
Copy link
Author

scabug commented Apr 6, 2012

@paulp said:
19bb173264

@scabug scabug closed this as completed Apr 6, 2012
@scabug scabug added this to the 2.10.0-M2 milestone Apr 7, 2017
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

2 participants