You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by MG <mg...@arscreat.com> on 2021/03/01 17:41:13 UTC
groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc: Internal
groovyc error: code 1 ?
Hi,
I tried to do a spike to switch the (large) IntelliJ build-based* Groovy
project I am working on to from Groovy 2.5.10 to the current Groovy 3
release (3.0.7) today, but immediately got a "Groovyc: Internal groovyc
error: code 1" that (contrary to previous times I encountered that
error) did not go away through a rebuild of the current module or the
whole project.
The same problem then occurred with the current Groovy 2.5 release (2.5.14).
I have now created a minimal IntelliJ Groovy project, that contains a
single test that outputs the Groovy version - and to my surprise this
still gives "Groovyc: Internal groovyc error: code 1" in the 'Builder
"Groovy stub generator" requested rebuild of module chunk
"GroovyMinimal"' phase...
The minimal project builds & runs without problems when switching back
to Groovy 2.5.10.
My complete build environment is:
IntellliJ 2020.2.3
AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using 11.0.10.5)
Windows 10 Pro 64-bit (build 19041.804)
Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
(Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
The project consists only of the (non-global) respective Groovy library
dependency, and the following Groovy test file (for simplicity I use the
JUnit that comes with this particular IntelliJ version in the minimal
project):
package minimal.groovy
import org.junit.Ignore import org.junit.Test class MinimalTest {
@Test @Ignore void test() {
println"Grooovy: ${GroovySystem.version}" }
}
Is this a known problem ? If not, feedback from other Groovy users would
be appreciated. I am evidently trying to find a solution to this
problem, but also to discern the extent of it: E.g. does it also occur
when using Maven or Gradle as a build system (which would surprise me,
since that is what most people use) ? If your build works fine with
Groovy 2.5.14 / 3.0.7, what is your build environment ?
Thanks, cheers,
mg
*Since the question typically pops up: The environment I work in does
not allow access to build repositories on the internet, and it is not
possible to automatically mirror repositories locally, and we have no
complicated build steps, so using Gradle (or Maven) would have no real
advantage for us, so we use the build system that is best integrated
with our IDE and has good (apart from some minor hickups) minimal
rebuild support, etc, i.e. an IntelliJ build.
groovy-3.0.7 build error: StringIndexOutOfBoundsException: String
index out of range: -1
Posted by MG <mg...@arscreat.com>.
...that must have been the weirdest bug I ever tracked down (did not
help that it was smack in the middle of a big class inside our largest
module):
https://issues.apache.org/jira/browse/GROOVY-9966
Issue 9966 feels like a fitting number for this one; fortunately error
conditions are so special (feels like a quantum superposition), that it
is really easy to work around, once found... ;-)
Cheers,
mg
-------- Forwarded Message --------
Subject: Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc:
Internal groovyc error: code 1 ?
Date: Wed, 3 Mar 2021 01:07:00 +0100
From: MG <mg...@arscreat.com>
Reply-To: users@groovy.apache.org
To: users@groovy.apache.org, Paul King <pa...@asert.com.au>
Hi Paul,
that did solve the problem, thank you - but it would be nice if an
oversight like that would not lead to a "no information" internal
compiler error for us poor no Maven/Gradle build people :-)
Besides some solvable/trivial ones, I encountered another surprising one
in StaticImportVisitor#getAccessorName (stacktrace below) - maybe coming
from the NV/NVL macro stubs, or static Table class members...
Cheers,
mg
Error:Groovyc: While compiling groovysql:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.base/java.lang.String.substring(String.java:1841)
at org.apache.groovy.util.BeanUtils.capitalize(BeanUtils.java:54)
at
org.codehaus.groovy.control.StaticImportVisitor.getAccessorName(StaticImportVisitor.java:519)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:528)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorGivenArgs(StaticImportVisitor.java:524)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticMethodImportFromModule(StaticImportVisitor.java:505)
at
org.codehaus.groovy.control.StaticImportVisitor.transformPropertyExpression(StaticImportVisitor.java:384)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:130)
at
org.codehaus.groovy.ast.expr.CastExpression.transformExpression(CastExpression.java:95)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.expr.DeclarationExpression.transformExpression(DeclarationExpression.java:183)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:108)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:133)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:242)
at
org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:47)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:111)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:66)
at
org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:108)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:106)
at
org.codehaus.groovy.ast.ClassNode.visitMethods(ClassNode.java:1099)
at
org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1092)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
at
org.codehaus.groovy.control.CompilationUnit.lambda$addPhaseOperations$3(CompilationUnit.java:209)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:942)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:107)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:90)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:175)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:94)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
On 01/03/2021 23:28, Paul King wrote:
> Just a complete guess but does your 3.0.7/2.5.14 global libraries
> include the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?
>
> On Tue, Mar 2, 2021 at 3:41 AM MG <mgbiz@arscreat.com
> <ma...@arscreat.com>> wrote:
>
> Hi,
>
> I tried to do a spike to switch the (large) IntelliJ build-based*
> Groovy project I am working on to from Groovy 2.5.10 to the
> current Groovy 3 release (3.0.7) today, but immediately got a
> "Groovyc: Internal groovyc error: code 1" that (contrary to
> previous times I encountered that error) did not go away through a
> rebuild of the current module or the whole project.
>
> The same problem then occurred with the current Groovy 2.5 release
> (2.5.14).
>
> I have now created a minimal IntelliJ Groovy project, that
> contains a single test that outputs the Groovy version - and to my
> surprise this still gives "Groovyc: Internal groovyc error: code
> 1" in the 'Builder "Groovy stub generator" requested rebuild of
> module chunk "GroovyMinimal"' phase...
> The minimal project builds & runs without problems when switching
> back to Groovy 2.5.10.
>
> My complete build environment is:
> IntellliJ 2020.2.3
> AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using
> 11.0.10.5)
> Windows 10 Pro 64-bit (build 19041.804)
> Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
> (Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
>
> The project consists only of the (non-global) respective Groovy
> library dependency, and the following Groovy test file (for
> simplicity I use the JUnit that comes with this particular
> IntelliJ version in the minimal project):
>
> package minimal.groovy
>
> import org.junit.Ignore import org.junit.Test class MinimalTest {
> @Test @Ignore void test() {
> println"Grooovy: ${GroovySystem.version}" }
> }
>
>
> Is this a known problem ? If not, feedback from other Groovy users
> would be appreciated. I am evidently trying to find a solution to
> this problem, but also to discern the extent of it: E.g. does it
> also occur when using Maven or Gradle as a build system (which
> would surprise me, since that is what most people use) ? If your
> build works fine with Groovy 2.5.14 / 3.0.7, what is your build
> environment ?
>
> Thanks, cheers,
> mg
>
> *Since the question typically pops up: The environment I work in
> does not allow access to build repositories on the internet, and
> it is not possible to automatically mirror repositories locally,
> and we have no complicated build steps, so using Gradle (or Maven)
> would have no real advantage for us, so we use the build system
> that is best integrated with our IDE and has good (apart from some
> minor hickups) minimal rebuild support, etc, i.e. an IntelliJ build.
>
>
>
>
>
>
>
groovy-3.0.7 build error: StringIndexOutOfBoundsException: String
index out of range: -1
Posted by MG <mg...@arscreat.com>.
...that must have been the weirdest bug I ever tracked down (did not
help that it was smack in the middle of a big class inside our largest
module):
https://issues.apache.org/jira/browse/GROOVY-9966
Issue 9966 feels like a fitting number for this one; fortunately error
conditions are so special (feels like a quantum superposition), that it
is really easy to work around, once found... ;-)
Cheers,
mg
-------- Forwarded Message --------
Subject: Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc:
Internal groovyc error: code 1 ?
Date: Wed, 3 Mar 2021 01:07:00 +0100
From: MG <mg...@arscreat.com>
Reply-To: users@groovy.apache.org
To: users@groovy.apache.org, Paul King <pa...@asert.com.au>
Hi Paul,
that did solve the problem, thank you - but it would be nice if an
oversight like that would not lead to a "no information" internal
compiler error for us poor no Maven/Gradle build people :-)
Besides some solvable/trivial ones, I encountered another surprising one
in StaticImportVisitor#getAccessorName (stacktrace below) - maybe coming
from the NV/NVL macro stubs, or static Table class members...
Cheers,
mg
Error:Groovyc: While compiling groovysql:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.base/java.lang.String.substring(String.java:1841)
at org.apache.groovy.util.BeanUtils.capitalize(BeanUtils.java:54)
at
org.codehaus.groovy.control.StaticImportVisitor.getAccessorName(StaticImportVisitor.java:519)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:528)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorGivenArgs(StaticImportVisitor.java:524)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticMethodImportFromModule(StaticImportVisitor.java:505)
at
org.codehaus.groovy.control.StaticImportVisitor.transformPropertyExpression(StaticImportVisitor.java:384)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:130)
at
org.codehaus.groovy.ast.expr.CastExpression.transformExpression(CastExpression.java:95)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.expr.DeclarationExpression.transformExpression(DeclarationExpression.java:183)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:108)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:133)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:242)
at
org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:47)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:111)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:66)
at
org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:108)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:106)
at
org.codehaus.groovy.ast.ClassNode.visitMethods(ClassNode.java:1099)
at
org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1092)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
at
org.codehaus.groovy.control.CompilationUnit.lambda$addPhaseOperations$3(CompilationUnit.java:209)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:942)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:107)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:90)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:175)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:94)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
On 01/03/2021 23:28, Paul King wrote:
> Just a complete guess but does your 3.0.7/2.5.14 global libraries
> include the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?
>
> On Tue, Mar 2, 2021 at 3:41 AM MG <mgbiz@arscreat.com
> <ma...@arscreat.com>> wrote:
>
> Hi,
>
> I tried to do a spike to switch the (large) IntelliJ build-based*
> Groovy project I am working on to from Groovy 2.5.10 to the
> current Groovy 3 release (3.0.7) today, but immediately got a
> "Groovyc: Internal groovyc error: code 1" that (contrary to
> previous times I encountered that error) did not go away through a
> rebuild of the current module or the whole project.
>
> The same problem then occurred with the current Groovy 2.5 release
> (2.5.14).
>
> I have now created a minimal IntelliJ Groovy project, that
> contains a single test that outputs the Groovy version - and to my
> surprise this still gives "Groovyc: Internal groovyc error: code
> 1" in the 'Builder "Groovy stub generator" requested rebuild of
> module chunk "GroovyMinimal"' phase...
> The minimal project builds & runs without problems when switching
> back to Groovy 2.5.10.
>
> My complete build environment is:
> IntellliJ 2020.2.3
> AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using
> 11.0.10.5)
> Windows 10 Pro 64-bit (build 19041.804)
> Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
> (Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
>
> The project consists only of the (non-global) respective Groovy
> library dependency, and the following Groovy test file (for
> simplicity I use the JUnit that comes with this particular
> IntelliJ version in the minimal project):
>
> package minimal.groovy
>
> import org.junit.Ignore import org.junit.Test class MinimalTest {
> @Test @Ignore void test() {
> println"Grooovy: ${GroovySystem.version}" }
> }
>
>
> Is this a known problem ? If not, feedback from other Groovy users
> would be appreciated. I am evidently trying to find a solution to
> this problem, but also to discern the extent of it: E.g. does it
> also occur when using Maven or Gradle as a build system (which
> would surprise me, since that is what most people use) ? If your
> build works fine with Groovy 2.5.14 / 3.0.7, what is your build
> environment ?
>
> Thanks, cheers,
> mg
>
> *Since the question typically pops up: The environment I work in
> does not allow access to build repositories on the internet, and
> it is not possible to automatically mirror repositories locally,
> and we have no complicated build steps, so using Gradle (or Maven)
> would have no real advantage for us, so we use the build system
> that is best integrated with our IDE and has good (apart from some
> minor hickups) minimal rebuild support, etc, i.e. an IntelliJ build.
>
>
>
>
>
>
>
Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc: Internal
groovyc error: code 1 ?
Posted by MG <mg...@arscreat.com>.
Hi Paul,
that did solve the problem, thank you - but it would be nice if an
oversight like that would not lead to a "no information" internal
compiler error for us poor no Maven/Gradle build people :-)
Besides some solvable/trivial ones, I encountered another surprising one
in StaticImportVisitor#getAccessorName (stacktrace below) - maybe coming
from the NV/NVL macro stubs, or static Table class members...
Cheers,
mg
Error:Groovyc: While compiling groovysql:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.base/java.lang.String.substring(String.java:1841)
at org.apache.groovy.util.BeanUtils.capitalize(BeanUtils.java:54)
at
org.codehaus.groovy.control.StaticImportVisitor.getAccessorName(StaticImportVisitor.java:519)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:528)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorGivenArgs(StaticImportVisitor.java:524)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticMethodImportFromModule(StaticImportVisitor.java:505)
at
org.codehaus.groovy.control.StaticImportVisitor.transformPropertyExpression(StaticImportVisitor.java:384)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:130)
at
org.codehaus.groovy.ast.expr.CastExpression.transformExpression(CastExpression.java:95)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.expr.DeclarationExpression.transformExpression(DeclarationExpression.java:183)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:108)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:133)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:242)
at
org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:47)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:111)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:66)
at
org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:108)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:106)
at org.codehaus.groovy.ast.ClassNode.visitMethods(ClassNode.java:1099)
at
org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1092)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
at
org.codehaus.groovy.control.CompilationUnit.lambda$addPhaseOperations$3(CompilationUnit.java:209)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:942)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:107)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:90)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:175)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:94)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
On 01/03/2021 23:28, Paul King wrote:
> Just a complete guess but does your 3.0.7/2.5.14 global libraries
> include the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?
>
> On Tue, Mar 2, 2021 at 3:41 AM MG <mgbiz@arscreat.com
> <ma...@arscreat.com>> wrote:
>
> Hi,
>
> I tried to do a spike to switch the (large) IntelliJ build-based*
> Groovy project I am working on to from Groovy 2.5.10 to the
> current Groovy 3 release (3.0.7) today, but immediately got a
> "Groovyc: Internal groovyc error: code 1" that (contrary to
> previous times I encountered that error) did not go away through a
> rebuild of the current module or the whole project.
>
> The same problem then occurred with the current Groovy 2.5 release
> (2.5.14).
>
> I have now created a minimal IntelliJ Groovy project, that
> contains a single test that outputs the Groovy version - and to my
> surprise this still gives "Groovyc: Internal groovyc error: code
> 1" in the 'Builder "Groovy stub generator" requested rebuild of
> module chunk "GroovyMinimal"' phase...
> The minimal project builds & runs without problems when switching
> back to Groovy 2.5.10.
>
> My complete build environment is:
> IntellliJ 2020.2.3
> AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using
> 11.0.10.5)
> Windows 10 Pro 64-bit (build 19041.804)
> Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
> (Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
>
> The project consists only of the (non-global) respective Groovy
> library dependency, and the following Groovy test file (for
> simplicity I use the JUnit that comes with this particular
> IntelliJ version in the minimal project):
>
> package minimal.groovy
>
> import org.junit.Ignore import org.junit.Test class MinimalTest {
> @Test @Ignore void test() {
> println"Grooovy: ${GroovySystem.version}" }
> }
>
>
> Is this a known problem ? If not, feedback from other Groovy users
> would be appreciated. I am evidently trying to find a solution to
> this problem, but also to discern the extent of it: E.g. does it
> also occur when using Maven or Gradle as a build system (which
> would surprise me, since that is what most people use) ? If your
> build works fine with Groovy 2.5.14 / 3.0.7, what is your build
> environment ?
>
> Thanks, cheers,
> mg
>
> *Since the question typically pops up: The environment I work in
> does not allow access to build repositories on the internet, and
> it is not possible to automatically mirror repositories locally,
> and we have no complicated build steps, so using Gradle (or Maven)
> would have no real advantage for us, so we use the build system
> that is best integrated with our IDE and has good (apart from some
> minor hickups) minimal rebuild support, etc, i.e. an IntelliJ build.
>
>
>
>
>
>
>
Re: groovy-3.0.7 & groovy-2.5.14 IntelliJ build => Groovyc: Internal
groovyc error: code 1 ?
Posted by Paul King <pa...@asert.com.au>.
Just a complete guess but does your 3.0.7/2.5.14 global libraries include
the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?
On Tue, Mar 2, 2021 at 3:41 AM MG <mg...@arscreat.com> wrote:
> Hi,
>
> I tried to do a spike to switch the (large) IntelliJ build-based* Groovy
> project I am working on to from Groovy 2.5.10 to the current Groovy 3
> release (3.0.7) today, but immediately got a "Groovyc: Internal groovyc
> error: code 1" that (contrary to previous times I encountered that error)
> did not go away through a rebuild of the current module or the whole
> project.
>
> The same problem then occurred with the current Groovy 2.5 release
> (2.5.14).
>
> I have now created a minimal IntelliJ Groovy project, that contains a
> single test that outputs the Groovy version - and to my surprise this still
> gives "Groovyc: Internal groovyc error: code 1" in the 'Builder "Groovy
> stub generator" requested rebuild of module chunk "GroovyMinimal"' phase...
> The minimal project builds & runs without problems when switching back to
> Groovy 2.5.10.
>
> My complete build environment is:
> IntellliJ 2020.2.3
> AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using 11.0.10.5)
> Windows 10 Pro 64-bit (build 19041.804)
> Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
> (Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
>
> The project consists only of the (non-global) respective Groovy library
> dependency, and the following Groovy test file (for simplicity I use the
> JUnit that comes with this particular IntelliJ version in the minimal
> project):
>
> package minimal.groovy
> import org.junit.Ignoreimport org.junit.Testclass MinimalTest {
> @Test @Ignore void test() {
> println "Grooovy: ${GroovySystem.version}" }
> }
>
>
> Is this a known problem ? If not, feedback from other Groovy users would
> be appreciated. I am evidently trying to find a solution to this problem,
> but also to discern the extent of it: E.g. does it also occur when using
> Maven or Gradle as a build system (which would surprise me, since that is
> what most people use) ? If your build works fine with Groovy 2.5.14 /
> 3.0.7, what is your build environment ?
>
> Thanks, cheers,
> mg
>
> *Since the question typically pops up: The environment I work in does not
> allow access to build repositories on the internet, and it is not possible
> to automatically mirror repositories locally, and we have no complicated
> build steps, so using Gradle (or Maven) would have no real advantage for
> us, so we use the build system that is best integrated with our IDE and has
> good (apart from some minor hickups) minimal rebuild support, etc, i.e. an
> IntelliJ build.
>
>
>
>
>
>
>
>