Scala 2.8.1 IDE bug, Eclipse 3.5 and 3.6.1 (FIXED,
November 11, 2010
FIXED, REALLY in Scala 2.9.0RC1 and corresponding version of Scala-IDE. No more crashes, fast-ish rebuilds, no deadlocks. This is much nicer. A little better with its memory consumption, too.
FIXED IN http://download.scala-ide.org/nightly-update-wip-experiment-trunk (This is a nightly build, based on latest as 2011-02-22, Scala 2.9.)
Unfortunately, this version of the plugin takes 7 times longer (45-50 minutes) to perform a from-scratch project rebuild, and incremental changes are just as costly as clean rebuilds. This is clearly not usable.
Looks like a dupe of #1000150, which is apparently “Invalid”. Not for me.
No earthly idea how to get “Assembla” to let me file a big or attach any information to the bug report, which is why I am writing it all down here.
eclipse.buildId=M20100909-0800 java.version=1.6.0_22 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/dr2chase/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -keyring /Users/dr2chase/.eclipse_keyring -showlocation
java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.initializeTypeVariable(BinaryTypeBinding.java:944) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createTypeVariables(BinaryTypeBinding.java:647) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:484) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:598) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:329) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:674) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:653) at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:108) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:851) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:100) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:1047) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.getMethods(BinaryTypeBinding.java:918) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1227) at org.eclipse.jdt.internal.compiler.lookup.Scope.findMethod(Scope.java:1198) at org.eclipse.jdt.internal.compiler.lookup.Scope.getMethod(Scope.java:2258) at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:403) at org.eclipse.jdt.internal.compiler.ast.Assignment.resolveType(Assignment.java:157) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:915) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:90) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:264) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:451) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:212) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:410) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1147) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1235) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:540) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:759) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137) at java.lang.Thread.run(Thread.java:680)
The input that made this happen was the Fortress source code.
It was suggested that perhaps this was caused by a version mismatch. I checked, and apparently it was not, but it took 40 minutes to check this (uninstall old, reinstall from verified new, wait for rebuild).
Next suggestion was to misinterpret my mail and recommend that I repeat the steps I had just performed.
Next suggestion was to start fresh with a toy program (funny, how all these suggestions involve me spending my time) in a freshly installed Eclipse and plugin. Did that, also tested the toy program in the bug-exhibiting Eclipse+plugin (because why wait for the obvious next step — it’s no surprise that a trivial program works in a clean environment).
If I didn’t know better, I’d say we had a developer in denial. “Can’t be my mistake, that dr2chase guy must just be an uck-fup who can’t do anything right”.
I am reminded, also, of a friend’s “killer app for Python” — when the application crashes in the field, Python emits a very informative stack trace. Their harness captures that stack trace, compresses it, and asks the user to please forward it to the developers, with the usual assurances about confidential info staying confidential. Developer opens informative package that contains all the automatically gathered relevant information, figures out bug, tests and posts a fix, and the next interaction with the customer is to tell them where to get their fix. Developer is productive, customer is happy and thinks that developer is a genius. Oddly enough, that doesn’t seem to be happening here.
Of course, there is a next step, try loading the bug-triggering project into the clean Eclipse, and see if it reoccurs there. 40 minutes later, bug repeats.
And finally, someone who knows how to fix it, looks at it. Yay!
Or not. It’s apparently still broken. But they’re working on it. With much fiddling, the performance of a rebuild has been delightfully improved, whether for success (2.8.0) or failure (2.8.1).