GRECLIPSE

[compiler] Greclipse runs into "Groovy bug" in simple Projects

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.1.2Release
  • Component/s: Compiler Integration
  • Labels:
    None
  • Environment:
  • Number of attachments :
    3

Description

Greclipse denies running even simple Groovy programs.
Without apparent reason the import statements get cluttered with messages like:

Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
java.lang.NullPointerException
at org.codehaus.groovy.ast.ASTNode.setSourcePosition(ASTNode.java:104)
at org.codehaus.groovy.classgen.ReturnAdder.addReturnIfNeeded(ReturnAdder.java:48)
at org.codehaus.groovy.classgen.Verifier.addReturnIfNeeded(Verifier.java:477)
at org.codehaus.groovy.classgen.Verifier.visitMethod(Verifier.java:454)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1097)
at org.codehaus.groovy.classgen.Verifier.visitClass(Verifier.java:176)
at org.codehaus.groovy.control.CompilationUnit$7.call(CompilationUnit.java:835)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1159)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:555)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:532)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:160)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1194)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:846)
at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:137)
at java.lang.Thread.run(Thread.java:619)

And:

Groovy bug when compiling.
BUG! exception in phase 'class generation' in source unit '/TR2/src/model/AccountIntervalManager.groovy' MapEntryExpression should not be visited here
at org.codehaus.groovy.classgen.AsmClassGenerator.visitMapEntryExpression(AsmClassGenerator.java:3098)
at org.codehaus.groovy.ast.expr.MapEntryExpression.visit(MapEntryExpression.java:37)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitAndAutoboxBoolean(AsmClassGenerator.java:4057)
at org.codehaus.groovy.classgen.AsmClassGenerator.makeBinopCallSite(AsmClassGenerator.java:2214)
at org.codehaus.groovy.classgen.AsmClassGenerator.evaluateBinaryExpression(AsmClassGenerator.java:3832)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:1610)
at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitAndAutoboxBoolean(AsmClassGenerator.java:4057)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitExpressionStatement(AsmClassGenerator.java:1423)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:176)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:703)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:51)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitForLoop(AsmClassGenerator.java:814)
at org.codehaus.groovy.ast.stmt.ForStatement.visit(ForStatement.java:47)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:176)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:703)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:51)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:98)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:109)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:582)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:558)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:120)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:660)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1097)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:51)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:272)
at org.codehaus.groovy.control.CompilationUnit$7.call(CompilationUnit.java:872)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1159)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:555)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:532)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:160)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.generateCode(GroovyCompilationUnitDeclaration.java:1194)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:968)
at org.eclipse.jdt.internal.compiler.Compiler.resolve(Compiler.java:1007)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:203)
at org.eclipse.jdt.internal.core.CompilationUnitProblemFinder.process(CompilationUnitProblemFinder.java:264)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.makeConsistent(ReconcileWorkingCopyOperation.java:190)
at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:89)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788)
at org.codehaus.jdt.groovy.model.GroovyCompilationUnit.reconcile(GroovyCompilationUnit.java:430)
at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1225)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:133)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andy Clement added a comment -

Thanks for raising the bug - can you attach any source? I can't recreate it.

The first exception looks related to adding a return where there isn't one (but one is required) - but nothing I try will fail.

Show
Andy Clement added a comment - Thanks for raising the bug - can you attach any source? I can't recreate it. The first exception looks related to adding a return where there isn't one (but one is required) - but nothing I try will fail.
Hide
Permalink
Andy Clement added a comment -

Any change of getting the source? I'd really like to fix this.

Show
Andy Clement added a comment - Any change of getting the source? I'd really like to fix this.
Hide
Permalink
Markus Günther added a comment -

Sorry this took so long.
I had to strip it down until it made no sense to my boss anymore (otherwise he wouldn't let me post it).
Hope it'll help you.

Show
Markus Günther added a comment - Sorry this took so long. I had to strip it down until it made no sense to my boss anymore (otherwise he wouldn't let me post it). Hope it'll help you.
Hide
Permalink
Andy Clement added a comment -

Hi - thanks for working on creating a minimal testcase. Unfortunately I've tried a few different ways and it just won't fail for me (Win 7 64bit but 32 bit sts and jvm)

Can you check what level of groovy eclipse you have installed? I'm guessing you have a 2.0.0 release? I've tried on the latest dev builds of greclipse 2.0.1 and it worked, I then went back and tried the 2.0.0 release and it worked there too.

Does the code fail for you on a full build or do you have to do an incremental build to cause it to go wrong? Do you have any other project configuration around (AST transforms?) - something funky on the classpath that defines an extra ast transform? The error message does perhaps suggest the issue is ast transform related... and that would explain why no-one else has reported it.

I've tried whitespace change and save with each of the 3 files (StateViolationException, AccountIntervalManager and TaskDateBracket) but each time it builds fine with no errors.

I tried groovy 1.6 and 1.7 and neither showed a problem (which are you using?)

Show
Andy Clement added a comment - Hi - thanks for working on creating a minimal testcase. Unfortunately I've tried a few different ways and it just won't fail for me (Win 7 64bit but 32 bit sts and jvm) Can you check what level of groovy eclipse you have installed? I'm guessing you have a 2.0.0 release? I've tried on the latest dev builds of greclipse 2.0.1 and it worked, I then went back and tried the 2.0.0 release and it worked there too. Does the code fail for you on a full build or do you have to do an incremental build to cause it to go wrong? Do you have any other project configuration around (AST transforms?) - something funky on the classpath that defines an extra ast transform? The error message does perhaps suggest the issue is ast transform related... and that would explain why no-one else has reported it. I've tried whitespace change and save with each of the 3 files (StateViolationException, AccountIntervalManager and TaskDateBracket) but each time it builds fine with no errors. I tried groovy 1.6 and 1.7 and neither showed a problem (which are you using?)
Hide
Permalink
Andy Clement added a comment -

I'm stilling trying to recreate this ... with no success.

Although you haven't told me what version of groovy you are on yet, it looks like 1.7 as the Verifier.java:477 line is only correct on that level.

This stack:

java.lang.NullPointerException
at org.codehaus.groovy.ast.ASTNode.setSourcePosition(ASTNode.java:104)
at org.codehaus.groovy.classgen.ReturnAdder.addReturnIfNeeded(ReturnAdder.java:48)
at org.codehaus.groovy.classgen.Verifier.addReturnIfNeeded(Verifier.java:477)
at org.codehaus.groovy.classgen.Verifier.visitMethod(Verifier.java:454)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1097)

suggests the call "node.getCode();" where node is a MethodNode is returning null. And the path taken within addReturnIfNeeded suggests it is a method with a void return type that is not abstract. Looking through the code you sent me, the methods that fit that description are start/stop and switchtask in AccountIntervalManager, but they all compile fine for me. It could be a generated method but that also fits the bill (generated setter for a property perhaps) but I just can't tell. I would rather not randomly guard for the NPE, so not able to progress this until I can recreate.

I suppose it is possible that the second exception gives rise to the first problem - are you able to say which order they come out in?

Show
Andy Clement added a comment - I'm stilling trying to recreate this ... with no success. Although you haven't told me what version of groovy you are on yet, it looks like 1.7 as the Verifier.java:477 line is only correct on that level. This stack: java.lang.NullPointerException at org.codehaus.groovy.ast.ASTNode.setSourcePosition(ASTNode.java:104) at org.codehaus.groovy.classgen.ReturnAdder.addReturnIfNeeded(ReturnAdder.java:48) at org.codehaus.groovy.classgen.Verifier.addReturnIfNeeded(Verifier.java:477) at org.codehaus.groovy.classgen.Verifier.visitMethod(Verifier.java:454) at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1097) suggests the call "node.getCode();" where node is a MethodNode is returning null. And the path taken within addReturnIfNeeded suggests it is a method with a void return type that is not abstract. Looking through the code you sent me, the methods that fit that description are start/stop and switchtask in AccountIntervalManager, but they all compile fine for me. It could be a generated method but that also fits the bill (generated setter for a property perhaps) but I just can't tell. I would rather not randomly guard for the NPE, so not able to progress this until I can recreate. I suppose it is possible that the second exception gives rise to the first problem - are you able to say which order they come out in?
Hide
Permalink
Markus Günther added a comment -

Groovy is 1.7, yes.

I use the foloowing version of STS:
Version: 2.3.0.RELEASE
Build Id: 200912171331
The Groovy Features identify as "Version 2.0.0.xx-20100115-e35-RELEASE"

And no, I'm not using any fancy stuff beyond Groovy and STS - and in this project I didn't even use any kind of metaprogramming or whatnot.

Sadly I cannot recreate the sequence in which the Exceptions occurrde.

BTW, there is another odd (and really disturbing) misbehaviour: my Greclipse has a way of generating import statements at the top of the file, even above the package declaration. Of course It immediately lets me know that that's a no-go. Really annoying.

Show
Markus Günther added a comment - Groovy is 1.7, yes. I use the foloowing version of STS: Version: 2.3.0.RELEASE Build Id: 200912171331 The Groovy Features identify as "Version 2.0.0.xx-20100115-e35-RELEASE" And no, I'm not using any fancy stuff beyond Groovy and STS - and in this project I didn't even use any kind of metaprogramming or whatnot. Sadly I cannot recreate the sequence in which the Exceptions occurrde. BTW, there is another odd (and really disturbing) misbehaviour: my Greclipse has a way of generating import statements at the top of the file, even above the package declaration. Of course It immediately lets me know that that's a no-go. Really annoying.
Hide
Permalink
Markus Günther added a comment -

One more thing, though:
I've had the same problems (though possibly with a slightly different stack) on my office machine (Win XP SP3, Groovy 1.6.?, same STS version as my home machine).

Show
Markus Günther added a comment - One more thing, though: I've had the same problems (though possibly with a slightly different stack) on my office machine (Win XP SP3, Groovy 1.6.?, same STS version as my home machine).
Hide
Permalink
Andy Clement added a comment -

a different stack would be interesting - please attach it if you see it again.

Until I can recreate, it isn't very easy for me to address this unfortunately.

> my Greclipse has a way of generating import statements at the top of the file, even above the package declaration. Of course It immediately lets me know that that's a no-go. Really annoying.

this is believed to be a problem with the parser recovery of groovy itself. In situations where the code won't parse (because you haven't finished working on the line you are currently typing on) we don't know where the package declaration is and the imports end up added at the wrong place. We are fixing groovy parsing as we go along, if you are able to give me a snippet of code that shows where the imminently added import goes in the wrong place, that would be useful.

Show
Andy Clement added a comment - a different stack would be interesting - please attach it if you see it again. Until I can recreate, it isn't very easy for me to address this unfortunately. > my Greclipse has a way of generating import statements at the top of the file, even above the package declaration. Of course It immediately lets me know that that's a no-go. Really annoying. this is believed to be a problem with the parser recovery of groovy itself. In situations where the code won't parse (because you haven't finished working on the line you are currently typing on) we don't know where the package declaration is and the imports end up added at the wrong place. We are fixing groovy parsing as we go along, if you are able to give me a snippet of code that shows where the imminently added import goes in the wrong place, that would be useful.
Hide
Permalink
aaron pieper added a comment -

We were running into the same issue this morning. We had written the following code in a JaxbTests.groovy file:

class JaxbTests extends GroovyTestCase {
@XmlRootElement
@XmlAccessorType(XmlAccessorType.NONE)
class JaxbRoot { @XmlAttribute String value }
}

There were two problems here. First of all, inner classes aren't allowed in Groovy. Secondly, the XmlAccessorType annotation takes an XmlAccessType argument; not an XmlAccessorType argument. However, instead of giving us the expected compiler errors, we received the internal compiler error (the exact NPE listed above).

Running a "grails test-app" from the command line gave us the correct compiler errors. Once we fixed those errors, the strange Greclipse behavior went away as well.

Show
aaron pieper added a comment - We were running into the same issue this morning. We had written the following code in a JaxbTests.groovy file: class JaxbTests extends GroovyTestCase { @XmlRootElement @XmlAccessorType(XmlAccessorType.NONE) class JaxbRoot { @XmlAttribute String value } } There were two problems here. First of all, inner classes aren't allowed in Groovy. Secondly, the XmlAccessorType annotation takes an XmlAccessType argument; not an XmlAccessorType argument. However, instead of giving us the expected compiler errors, we received the internal compiler error (the exact NPE listed above). Running a "grails test-app" from the command line gave us the correct compiler errors. Once we fixed those errors, the strange Greclipse behavior went away as well.
Hide
Permalink
Andy Clement added a comment -

I took your snippet and defined it in a groovy project. I added the dependencies relating to JAXB (I used 2.2), I then got:

BUG! exception in phase 'class generation' in source unit '/Aardvark/src/Test1.groovy' ClassNode#getTypeClass for javax.xml.bind.annotation.XmlAccessorType is called before the type class is set 
	at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1342)
	at org.codehaus.groovy.classgen.AnnotationVisitor.transformInlineConstants(AnnotationVisitor.java:91)
	at org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:71)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:173)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:124)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:63)
	at org.codehaus.groovy.control.CompilationUnit$7.call(CompilationUnit.java:851)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1159)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)

which is another bug I've recently fixed. So I picked up the latest dev build that fixes this, now all I get is this (which I presume is the expected error):

Groovy:Attribute 'value' should have type 'javax.xml.bind.annotation.XmlAccessType' (Enum), but found javax.xml.bind.annotation.XmlAccessorType in @javax.xml.bind.annotation.XmlAccessorType

> First of all, inner classes aren't allowed in Groovy

They are in 1.7. Were you using 1.6?

I repeated all my testing with 1.6 and got this error:

Groovy:Class definition not expected here. Possible attempt to use inner class. Inner classes not supported, perhaps try using a closure instead.

which is what we'd expect against 1.6.

So unfortunately i'm no closer to recreating the original problem here.

Show
Andy Clement added a comment - I took your snippet and defined it in a groovy project. I added the dependencies relating to JAXB (I used 2.2), I then got: 
BUG! exception in phase 'class generation' in source unit '/Aardvark/src/Test1.groovy' ClassNode#getTypeClass for javax.xml.bind.annotation.XmlAccessorType is called before the type class is set 
	at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1342)
	at org.codehaus.groovy.classgen.AnnotationVisitor.transformInlineConstants(AnnotationVisitor.java:91)
	at org.codehaus.groovy.classgen.AnnotationVisitor.visit(AnnotationVisitor.java:71)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotation(ExtendedVerifier.java:173)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitAnnotations(ExtendedVerifier.java:124)
	at org.codehaus.groovy.classgen.ExtendedVerifier.visitClass(ExtendedVerifier.java:63)
	at org.codehaus.groovy.control.CompilationUnit$7.call(CompilationUnit.java:851)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1159)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:577)
which is another bug I've recently fixed. So I picked up the latest dev build that fixes this, now all I get is this (which I presume is the expected error): 
Groovy:Attribute 'value' should have type 'javax.xml.bind.annotation.XmlAccessType' (Enum), but found javax.xml.bind.annotation.XmlAccessorType in @javax.xml.bind.annotation.XmlAccessorType
> First of all, inner classes aren't allowed in Groovy They are in 1.7. Were you using 1.6? I repeated all my testing with 1.6 and got this error: Groovy:Class definition not expected here. Possible attempt to use inner class. Inner classes not supported, perhaps try using a closure instead. which is what we'd expect against 1.6. So unfortunately i'm no closer to recreating the original problem here.
Hide
Permalink
Michael Borgwardt added a comment -

This reproduces the bug for me

Show
Michael Borgwardt added a comment - This reproduces the bug for me
Hide
Permalink
Michael Borgwardt added a comment -

I've run into this bug in my project as well; I've stripped it down to the minimum number of classes required to reproduce it and attached those. It seems to be related to having a Groovy class (or enum) import both a regular Groovy class and a Java class that has an inner class of the same name as the Groovy class.

My environment:
Spring IDE 2.3.3.201004042100-CI-R3754-B700
Groovy-Eclipse plugin 2.0.1.20100317-1100-e35
STS 2.3.3.CI-R4864-B175
JDK 1.6.0_19
Eclipse 3.5.2.R35x_v20100210-0800-9

Show
Michael Borgwardt added a comment - I've run into this bug in my project as well; I've stripped it down to the minimum number of classes required to reproduce it and attached those. It seems to be related to having a Groovy class (or enum) import both a regular Groovy class and a Java class that has an inner class of the same name as the Groovy class. My environment: Spring IDE 2.3.3.201004042100-CI-R3754-B700 Groovy-Eclipse plugin 2.0.1.20100317-1100-e35 STS 2.3.3.CI-R4864-B175 JDK 1.6.0_19 Eclipse 3.5.2.R35x_v20100210-0800-9
Hide
Permalink
Michael Borgwardt added a comment -

Curious and curiouser. I've found that the error even occurs when ImageSortField.groovy does not refer the other classes at all, but disappears when they are deleted and reappears when they are restored. Also, the first letter of the package declaration has a different style. See attached screenshot.

Show
Michael Borgwardt added a comment - Curious and curiouser. I've found that the error even occurs when ImageSortField.groovy does not refer the other classes at all, but disappears when they are deleted and reappears when they are restored. Also, the first letter of the package declaration has a different style. See attached screenshot.
Hide
Permalink
Andy Clement added a comment -

Thanks for the testcode, blows up on the command line too (with the "MapEntryExpression should not be visited here" error) so not a groovy-eclipse issue, it is a groovy issue. I raised http://jira.codehaus.org/browse/GROOVY-4219 to cover the groovy fix. When they fix it, I'll pick it up in groovy-eclipse.

Show
Andy Clement added a comment - Thanks for the testcode, blows up on the command line too (with the "MapEntryExpression should not be visited here" error) so not a groovy-eclipse issue, it is a groovy issue. I raised http://jira.codehaus.org/browse/GROOVY-4219 to cover the groovy fix. When they fix it, I'll pick it up in groovy-eclipse.
Hide
Permalink
Michael Borgwardt added a comment -

Judging from the comments on GROOVY-3613, the root of the problem seems to be that enum constructors don't support named parameters. That's inconsistent language design but not necessarily a bug. What I do consider a bug is the lack of an understandable and compiler error. Especially in groovy eclipse, the error message is not helpful at all AND is located spuriously in different classes that have nothing at all to do with the problem.

Show
Michael Borgwardt added a comment - Judging from the comments on GROOVY-3613, the root of the problem seems to be that enum constructors don't support named parameters. That's inconsistent language design but not necessarily a bug. What I do consider a bug is the lack of an understandable and compiler error. Especially in groovy eclipse, the error message is not helpful at all AND is located spuriously in different classes that have nothing at all to do with the problem.
Hide
Permalink
Andy Clement added a comment -

yep, i agree. it shouldn't be possible to crash the compiler, regardless of code validity.

Show
Andy Clement added a comment - yep, i agree. it shouldn't be possible to crash the compiler, regardless of code validity.
Hide
Permalink
Andy Clement added a comment -

i guess we could improve our error handling in greclipse as unfortunately it is not uncommon to crash groovyc. If we unwrapped the root BUG! we would discover the file that blew up. Although it may not be possible to record the error correctly against that file I'm afraid, due to the way in which groovy processing runs. It is really a fatal error though, not a regular compiler error - so the cause of the error will be cryptic.

Show
Andy Clement added a comment - i guess we could improve our error handling in greclipse as unfortunately it is not uncommon to crash groovyc. If we unwrapped the root BUG! we would discover the file that blew up. Although it may not be possible to record the error correctly against that file I'm afraid, due to the way in which groovy processing runs. It is really a fatal error though, not a regular compiler error - so the cause of the error will be cryptic.
Hide
Permalink
Andy Clement added a comment -

quite an old bug and done all I plan to here, the groovy bug referenced is now fixed and we picked up that fixed when updating our internal groovy version.

Show
Andy Clement added a comment - quite an old bug and done all I plan to here, the groovy bug referenced is now fixed and we picked up that fixed when updating our internal groovy version.

People

Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.