New Compile failure when upgrading from 1.7.1 to 1.8.0

Guillaume Laforge added a comment - 17/Jun/11 3:04 PM Please provide a sample class that exhibits that compilation problem, otherwise, it'll be difficult for us to find the cause.

Jay Guidos added a comment - 17/Jun/11 4:46 PM Was caused by having some code compiled by 1.7.1 and some by 1.8.0. When I recompiled all code using only 1.8.0 the BUG report went away.

Jay Guidos added a comment - 17/Jun/11 6:24 PM Problem still exists - I have more diagnostics now

Jay Guidos added a comment - 17/Jun/11 6:33 PM - edited Comment deleted

Jay Guidos added a comment - 17/Jun/11 7:09 PM Shares classes with @Immutable

Jay Guidos added a comment - 17/Jun/11 7:09 PM Problem class

Jay Guidos added a comment - 17/Jun/11 7:12 PM I have attached a test case. I am betting the root problem is an issue with @Immutable. Compiling the test code will work until you uncomment the method in TestCRDConnector. If you do so, you will see the following error: BUG! exception in phase 'class generation' in source unit '/home/bidsjagu/java/GroovyBug/src/TestCRDConnector.groovy' Type is null. Most probably you let a transform reuse existing ClassNodes with generics information, that is now used in a wrong context. at org.codehaus.groovy.vmplugin.v5.Java5.configureType(Java5.java:96) at org.codehaus.groovy.vmplugin.v5.Java5.configureTypeArguments(Java5.java:157) at org.codehaus.groovy.vmplugin.v5.Java5.configureParameterizedType(Java5.java:137) at org.codehaus.groovy.vmplugin.v5.Java5.configureType(Java5.java:88) at org.codehaus.groovy.vmplugin.v5.Java5.makeClassNode(Java5.java:383) at org.codehaus.groovy.vmplugin.v5.Java5.makeParameter(Java5.java:402) at org.codehaus.groovy.vmplugin.v5.Java5.makeParameters(Java5.java:395) at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:340) at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:264) at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:974) at org.codehaus.groovy.ast.ClassNode.getUnresolvedSuperClass(ClassNode.java:969) at org.codehaus.groovy.ast.ClassNode.getSuperClass(ClassNode.java:963) at org.codehaus.groovy.ast.ClassNode.isDerivedFrom(ClassNode.java:906) at org.codehaus.groovy.classgen.asm.OperandStack.doConvertAndCast(OperandStack.java:290) at org.codehaus.groovy.classgen.asm.OperandStack.doAsType(OperandStack.java:274) at org.codehaus.groovy.classgen.AsmClassGenerator.visitCastExpression(AsmClassGenerator.java:630) at org.codehaus.groovy.ast.expr.CastExpression.visit(CastExpression.java:66) at org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateEqual(BinaryExpressionHelper.java:279) at org.codehaus.groovy.classgen.AsmClassGenerator.visitDeclarationExpression(AsmClassGenerator.java:521) at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:85) at org.codehaus.groovy.classgen.asm.StatementWriter.writeExpressionStatement(StatementWriter.java:599) at org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeExpressionStatement(OptimizingStatementWriter.java:323) at org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:460) at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40) at org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:80) at org.codehaus.groovy.classgen.asm.OptimizingStatementWriter.writeBlockStatement(OptimizingStatementWriter.java:151) at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:406) at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:101) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:112) at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:289) at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:268) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123) at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366) at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50) at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174) at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497) at org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:43) at org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)

Jay Guidos added a comment - 18/Jun/11 12:56 PM Hi Paul, Thanks for taking a look. I was having problems reproducing it all the time - sometimes it happens, sometimes not. I think I can reproduce it reliably now with the two files I gave you. If you compile both classes from scratch there are no problems. If you then edit the TestCRDConnector.groovy file (any change will do) and then recompile without changing the Shares.groovy class then I can reliably reproduce the above stack trace. So the problem seems to be how the groovy compiler is re-loading the already compiled class file for Shares.groovy, and may not be connected to how TestCRDConnector actually uses Shares. I am not sure why you needed to include the Immutable import, I seem to be able to compile successfully (from scratch) without doing that. I can upload the entire IntelliJ 10.5 project if you think that would help, it is only those two files you have already seen plus a project config directory.

Paul King added a comment - 19/Jun/11 4:50 AM Haven't had time to try recompiling just yet. Just on the import, groovy.lang.Immutable is deprecated - everyone should be using groovy.transform.Immutable these days - I was just suggesting the import to remove that potential complication from the mix.

Jay Guidos added a comment - 20/Jun/11 9:54 AM I had a go using the non-deprecated version of Immutable, with no change in results.

Jan Ahrens added a comment - 22/Jun/11 6:59 AM I can reproduce this bug, too. It appears from time to time in my groovy project, when I'm trying to compile certain classes. I have not fully identified what classes cause this bug to appear, so I can't attach another example. Rebuilding the whole project helps though. Below is my setup and how I was able to reproduce the bug, using the files Jay provided. I added an import to 'groovy.transform.Immutable' in Shares.groovy and uncommented the line in TestCRDConnector.groovy. $ uname -a Linux box 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux $ java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) $ groovyc -version Groovy compiler version 1.8.0 Copyright 2003-2010 The Codehaus. http://groovy.codehaus.org/ $ groovyc Shares.groovy $ groovyc TestCRDConnector.groovy >>> a serious error occurred: BUG! exception in phase 'class generation' in source unit 'TestCRDConnector.groovy' Type is null. Most probably you let a transform reuse existing ClassNodes with generics information, that is now used in a wrong context. >>> stacktrace: same stacktrace as above

Pascal Schumacher added a comment - 01/Apr/13 5:56 AM I used the same steps as in Jan Ahrens last comment, but could not reproduce this with Groovy 2.1.2, so I'm closing this issue.