[jira] [Commented] (GROOVY-8792) groovy-json not working from Ant task
[
https://issues.apache.org/jira/browse/GROOVY-8792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722400#comment-16722400
]
Paul King commented on GROOVY-8792:
---
Just got around to looking at this. It works for me with:
{code}
>
>
>
>
> {code}
> Build output:
> {code:xml}
> BUILD FAILED
> C:\test2\build.xml:8: java.lang.RuntimeException: Unable to load
> FastStringService
> at
> org.apache.groovy.json.internal.FastStringUtils.getService(FastStringUtils.java:57)
> at
> org.apache.groovy.json.internal.FastStringUtils.toCharArray(FastStringUtils.java:67)
> at
> org.apache.groovy.json.internal.BaseJsonParser.parse(BaseJsonParser.java:112)
> at groovy.json.JsonSlurper.parseText(JsonSlurper.java:205)
> at groovy.json.JsonSlurper$parseText.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
> at
> embedded_script_in_C__test2_build_dot_xml.run(embedded_script_in_C__test2_build_dot_xml:2)
> at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:517)
> at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:464)
> at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:322)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.Main.runBuild(Main.java:851)
> at org.apache.tools.ant.Main.startAnt(Main.java:235)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-3360) Better error message for assert a = 1
[
https://issues.apache.org/jira/browse/GROOVY-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King closed GROOVY-3360.
-
Resolution: Fixed
Assignee: Daniel Sun
Fix Version/s: (was: 4.x)
3.0.0-alpha-4
The Parrot parser already gives:
Assignment expression is not allowed in the assert statement
> Better error message for assert a = 1
> -
>
> Key: GROOVY-3360
> URL: https://issues.apache.org/jira/browse/GROOVY-3360
> Project: Groovy
> Issue Type: Improvement
> Components: parser-antlr2
>Reporter: Guillaume Delcroix
>Assignee: Daniel Sun
>Priority: Major
> Labels: contrib
> Fix For: 3.0.0-alpha-4
>
>
> The error message for this:
> {code}
> assert a = 1
> {code}
> could be a bit nicer instead of:
> {code}
> unexpected token '='
> {code}
> it could say that it's a comparison operator that is expected there or more
> generally a boolean expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-3539) Some uses of SyntaxErrorMessage are semantic error exceptions not syntax exceptions
[
https://issues.apache.org/jira/browse/GROOVY-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3539:
--
Description:
This program causes the compiler to throw a syntax error. However it should be
a semantic error.
{code}
public class B {
public void Test() {
new NotExist()
}
}
{code}
We could review usage of {{SyntaxErrorMessage}} and throw a different error
instead where appropriate.
They are converted into compilation exceptions later so not really visible to
users of the language but relevant for IDEs.
was:
This program causes the compiler to throw a syntax error. However it should be
a semantic error.
{code}
public class B {
public void Test() {
new NotExist()
}
}
{code}
> Some uses of SyntaxErrorMessage are semantic error exceptions not syntax
> exceptions
> ---
>
> Key: GROOVY-3539
> URL: https://issues.apache.org/jira/browse/GROOVY-3539
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 1.6.3
>Reporter: Andrew Eisenberg
>Priority: Minor
> Labels: contrib
>
> This program causes the compiler to throw a syntax error. However it should
> be a semantic error.
> {code}
> public class B {
>public void Test() {
> new NotExist()
>}
> }
> {code}
> We could review usage of {{SyntaxErrorMessage}} and throw a different error
> instead where appropriate.
> They are converted into compilation exceptions later so not really visible to
> users of the language but relevant for IDEs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-3539) Some uses of SyntaxErrorMessage are semantic error exceptions not syntax exceptions
[
https://issues.apache.org/jira/browse/GROOVY-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-3539:
--
Summary: Some uses of SyntaxErrorMessage are semantic error exceptions not
syntax exceptions (was: Syntax error thrown, but should be semantic error)
> Some uses of SyntaxErrorMessage are semantic error exceptions not syntax
> exceptions
> ---
>
> Key: GROOVY-3539
> URL: https://issues.apache.org/jira/browse/GROOVY-3539
> Project: Groovy
> Issue Type: Improvement
> Components: Compiler
>Affects Versions: 1.6.3
>Reporter: Andrew Eisenberg
>Priority: Minor
> Labels: contrib
>
> This program causes the compiler to throw a syntax error. However it should
> be a semantic error.
> {code}
> public class B {
>public void Test() {
> new NotExist()
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GROOVY-8838) assert in groovy does not produce any result
[ https://issues.apache.org/jira/browse/GROOVY-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-8838. - Resolution: Not A Problem Assignee: Paul King No further comments - assuming this is expected behavior. > assert in groovy does not produce any result > > > Key: GROOVY-8838 > URL: https://issues.apache.org/jira/browse/GROOVY-8838 > Project: Groovy > Issue Type: Bug > Components: groovy-jdk >Affects Versions: 2.4.3 >Reporter: Thulsi Doss Krishnan >Assignee: Paul King >Priority: Major > Labels: simple-assert- > Attachments: GroovyAssert.JPG > > > Hi running a simple assert does not produce any result in the eclipse IDE > def map1 = [user: 'mrhaki', likes: 'Groovy', age: 37] > def map2 = [age: 37.0, likes: 'Groovy', user: 'mrhaki'] > def map3 = [user: 'Hubert Klein Ikkink', likes: 'Groovy'] > assert map1.equals(map2) > assert map1 == map2 > assert !map1.equals(map3) > assert map2 != map3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-4063) Debugger Step Into doesn't work in Groovy-compiled classes when stepping filters are applied
[
https://issues.apache.org/jira/browse/GROOVY-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-4063.
---
Resolution: Duplicate
This seems to work with 2.4.16 and 2.5.5-SNAPSHOT, I presume it was fixed by
GROOVY-8742.
> Debugger Step Into doesn't work in Groovy-compiled classes when stepping
> filters are applied
>
>
> Key: GROOVY-4063
> URL: https://issues.apache.org/jira/browse/GROOVY-4063
> Project: Groovy
> Issue Type: Bug
> Components: class generator
>Affects Versions: 1.6.7, 1.7.0
>Reporter: Peter Gromov
>Priority: Major
> Attachments: debug-test.tar.gz
>
>
> Reproduced in IntelliJ IDEA 9, GroovyEclipse 2.0 and JSWAT 4.5, therefore the
> problem is probably in Groovy itself.
> Stepping class exclusion filters are set to ignore everything from Java and
> Groovy internals: groovy.*,org.codehaus.groovy.*,java.*,sun.*,org.apache.*
> {code}
> class Some {
> static void meth() {
> println "Method is called."
> }
> public static void main(String[] args) {
> meth() // breakpoint here
> }
> }
> {code}
> Run to the breakpoint in 'main' method. 'Step into'. There's a very long
> pause (presumably JVM applies the filters to all the underlying groovy
> internals), the message is printed and the program exits. Breakpoint is not
> hit.
> Now put the breakpoint to the 'println' line in 'meth' and repeat stepping
> into. This time the debugger stops at it.
> Stepping worked in earlier Groovy versions (e.g. 1.5) and stopped in 1.6.
> Therefore I suspect it to be somehow mystically related to class generation
> (or the libraries used, whatever)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8772) Groovy debugger is on the wrong line when exiting a try/catch
[
https://issues.apache.org/jira/browse/GROOVY-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722368#comment-16722368
]
Paul King edited comment on GROOVY-8772 at 12/16/18 3:21 AM:
-
My code is changed to be also valid Java code to allow me to compare with Java.
In IDEA with 2.4.15, I see (as per issue description):
# stop at line {{int a = 123;}}
# step to line {{System.out.println(s);}}
# step to line {{System.out.println("what just happened?");}}
In IDEA with 2.4.16, Groovy-2.5.5-SNAPSHOT and Groovy 3.0.0-SNAPSHOT, I see:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{} // after catch}}
# step to line {{System.out.println("what just happened?");}}
I thought I was seeing different behavior between 2.4.16 and the others but I
possibly was using an older jar. They seem similar now.
was (Author: paulk):
In IDEA with 2.4.16 I see:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{} // after catch}}
# step to line {{System.out.println("what just happened?");}}
> Groovy debugger is on the wrong line when exiting a try/catch
> -
>
> Key: GROOVY-8772
> URL: https://issues.apache.org/jira/browse/GROOVY-8772
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
>Reporter: David Pociu
>Priority: Critical
> Attachments: image.png, image1.png, image2.png
>
>
> Complete report also filed with IntelliJ Idea at
> [https://youtrack.jetbrains.com/issue/IDEA-198280]
> In the following code snippet:
>
>
> {code:java}
> package aaa
> /**
> * Created by D. Pociu - InsiTech on 9/3/2018.
> */
> class Main1 {
> static void main(String[] args){
>println "Hello"
>try{
> int a = 123;
>} catch (Exception ex){
> String s = ex.getMessage()
> println s
>}
>println "what just happened?"
> }
> }{code}
>
>
> If we set a debug point at the 'println "Hello" line and go inside the
> try/catch using the debugger, the next line after 'int a = 123' that the
> debugger stops on should be 'println "what just happened?"' , but instead is
> 'println s'.
> So the debugger jumps to the last line of the catch (visually, not any of the
> variables, or anything) , when visually it should be at the first line after
> the catch if no exception has been thrown.
> This creates GREAT confusion when I'm trying to debug complex classes because
> it gives the impression that the catch clause has been triggered when it has
> not.
> See attached screenshots of the step by step:
>
> Here's what the guys at Jetbrains had to say (see link above also):
>
> _Peter Gromov commented 6 hours ago_
> _Yes. The same problem is reproducible in Eclipse, so [David
> P.|https://youtrack.jetbrains.com/users/dpociu] could you please report the
> issue to Groovy compiler team? See
> [http://groovy-lang.org/reporting-issues.html]_
> __
> _Egor Ushakov commented 7 hours ago_
> _[Peter Gromov|https://youtrack.jetbrains.com/users/peter] it seems that
> groovy compiler does not generate line info for the location right after the
> try block (but stops there in debugger)._
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8772) Groovy debugger is on the wrong line when exiting a try/catch
[
https://issues.apache.org/jira/browse/GROOVY-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722368#comment-16722368
]
Paul King commented on GROOVY-8772:
---
In IDEA with 2.4.16 I see:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{} // after catch}}
# step to line {{System.out.println("what just happened?");}}
> Groovy debugger is on the wrong line when exiting a try/catch
> -
>
> Key: GROOVY-8772
> URL: https://issues.apache.org/jira/browse/GROOVY-8772
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
>Reporter: David Pociu
>Priority: Critical
> Attachments: image.png, image1.png, image2.png
>
>
> Complete report also filed with IntelliJ Idea at
> [https://youtrack.jetbrains.com/issue/IDEA-198280]
> In the following code snippet:
>
>
> {code:java}
> package aaa
> /**
> * Created by D. Pociu - InsiTech on 9/3/2018.
> */
> class Main1 {
> static void main(String[] args){
>println "Hello"
>try{
> int a = 123;
>} catch (Exception ex){
> String s = ex.getMessage()
> println s
>}
>println "what just happened?"
> }
> }{code}
>
>
> If we set a debug point at the 'println "Hello" line and go inside the
> try/catch using the debugger, the next line after 'int a = 123' that the
> debugger stops on should be 'println "what just happened?"' , but instead is
> 'println s'.
> So the debugger jumps to the last line of the catch (visually, not any of the
> variables, or anything) , when visually it should be at the first line after
> the catch if no exception has been thrown.
> This creates GREAT confusion when I'm trying to debug complex classes because
> it gives the impression that the catch clause has been triggered when it has
> not.
> See attached screenshots of the step by step:
>
> Here's what the guys at Jetbrains had to say (see link above also):
>
> _Peter Gromov commented 6 hours ago_
> _Yes. The same problem is reproducible in Eclipse, so [David
> P.|https://youtrack.jetbrains.com/users/dpociu] could you please report the
> issue to Groovy compiler team? See
> [http://groovy-lang.org/reporting-issues.html]_
> __
> _Egor Ushakov commented 7 hours ago_
> _[Peter Gromov|https://youtrack.jetbrains.com/users/peter] it seems that
> groovy compiler does not generate line info for the location right after the
> try block (but stops there in debugger)._
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-8772) Groovy debugger is on the wrong line when exiting a try/catch
[
https://issues.apache.org/jira/browse/GROOVY-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722186#comment-16722186
]
Eric Milles edited comment on GROOVY-8772 at 12/15/18 3:15 PM:
---
The behavior I see in the Java debugger (of Eclipse) is:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{System.err.println("what just happened?");}}
Groovy version adds stop at closing "}" of catch block between 2 and 3. Is
this the behavior you are seeing with Groovy 2.4.16 or 2.5.5?
was (Author: emilles):
The behavior I see in the Java debugger (of Eclipse) is:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{System.err.println("what just happened?");}}
Groovy version adds stop at closing "}" of try block between 2 and 3. Is this
the behavior you are seeing with Groovy 2.4.16 or 2.5.5?
> Groovy debugger is on the wrong line when exiting a try/catch
> -
>
> Key: GROOVY-8772
> URL: https://issues.apache.org/jira/browse/GROOVY-8772
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
>Reporter: David Pociu
>Priority: Critical
> Attachments: image.png, image1.png, image2.png
>
>
> Complete report also filed with IntelliJ Idea at
> [https://youtrack.jetbrains.com/issue/IDEA-198280]
> In the following code snippet:
>
>
> {code:java}
> package aaa
> /**
> * Created by D. Pociu - InsiTech on 9/3/2018.
> */
> class Main1 {
> static void main(String[] args){
>println "Hello"
>try{
> int a = 123;
>} catch (Exception ex){
> String s = ex.getMessage()
> println s
>}
>println "what just happened?"
> }
> }{code}
>
>
> If we set a debug point at the 'println "Hello" line and go inside the
> try/catch using the debugger, the next line after 'int a = 123' that the
> debugger stops on should be 'println "what just happened?"' , but instead is
> 'println s'.
> So the debugger jumps to the last line of the catch (visually, not any of the
> variables, or anything) , when visually it should be at the first line after
> the catch if no exception has been thrown.
> This creates GREAT confusion when I'm trying to debug complex classes because
> it gives the impression that the catch clause has been triggered when it has
> not.
> See attached screenshots of the step by step:
>
> Here's what the guys at Jetbrains had to say (see link above also):
>
> _Peter Gromov commented 6 hours ago_
> _Yes. The same problem is reproducible in Eclipse, so [David
> P.|https://youtrack.jetbrains.com/users/dpociu] could you please report the
> issue to Groovy compiler team? See
> [http://groovy-lang.org/reporting-issues.html]_
> __
> _Egor Ushakov commented 7 hours ago_
> _[Peter Gromov|https://youtrack.jetbrains.com/users/peter] it seems that
> groovy compiler does not generate line info for the location right after the
> try block (but stops there in debugger)._
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8772) Groovy debugger is on the wrong line when exiting a try/catch
[
https://issues.apache.org/jira/browse/GROOVY-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722186#comment-16722186
]
Eric Milles commented on GROOVY-8772:
-
The behavior I see in the Java debugger (of Eclipse) is:
# stop at line {{int a = 123;}}
# step to line {{} catch (Exception ex) {}}
# step to line {{System.err.println("what just happened?");}}
Groovy version adds stop at closing "}" of try block between 2 and 3. Is this
the behavior you are seeing with Groovy 2.4.16 or 2.5.5?
> Groovy debugger is on the wrong line when exiting a try/catch
> -
>
> Key: GROOVY-8772
> URL: https://issues.apache.org/jira/browse/GROOVY-8772
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
>Reporter: David Pociu
>Priority: Critical
> Attachments: image.png, image1.png, image2.png
>
>
> Complete report also filed with IntelliJ Idea at
> [https://youtrack.jetbrains.com/issue/IDEA-198280]
> In the following code snippet:
>
>
> {code:java}
> package aaa
> /**
> * Created by D. Pociu - InsiTech on 9/3/2018.
> */
> class Main1 {
> static void main(String[] args){
>println "Hello"
>try{
> int a = 123;
>} catch (Exception ex){
> String s = ex.getMessage()
> println s
>}
>println "what just happened?"
> }
> }{code}
>
>
> If we set a debug point at the 'println "Hello" line and go inside the
> try/catch using the debugger, the next line after 'int a = 123' that the
> debugger stops on should be 'println "what just happened?"' , but instead is
> 'println s'.
> So the debugger jumps to the last line of the catch (visually, not any of the
> variables, or anything) , when visually it should be at the first line after
> the catch if no exception has been thrown.
> This creates GREAT confusion when I'm trying to debug complex classes because
> it gives the impression that the catch clause has been triggered when it has
> not.
> See attached screenshots of the step by step:
>
> Here's what the guys at Jetbrains had to say (see link above also):
>
> _Peter Gromov commented 6 hours ago_
> _Yes. The same problem is reproducible in Eclipse, so [David
> P.|https://youtrack.jetbrains.com/users/dpociu] could you please report the
> issue to Groovy compiler team? See
> [http://groovy-lang.org/reporting-issues.html]_
> __
> _Egor Ushakov commented 7 hours ago_
> _[Peter Gromov|https://youtrack.jetbrains.com/users/peter] it seems that
> groovy compiler does not generate line info for the location right after the
> try block (but stops there in debugger)._
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GROOVY-7409) Closure reference a wrong object when is defining inside an iterator
[
https://issues.apache.org/jira/browse/GROOVY-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paolo di tommaso resolved GROOVY-7409.
--
Resolution: Not A Bug
Yes. Closing as not a bug. Quite tricky tho.
> Closure reference a wrong object when is defining inside an iterator
> -
>
> Key: GROOVY-7409
> URL: https://issues.apache.org/jira/browse/GROOVY-7409
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.11, 2.4.3
>Reporter: paolo di tommaso
>Priority: Critical
>
> A closure defined inside an iterator containing a reference to the iterating
> item resolves a wrong object instance.
> To reproduce the error take in consideration the following snippet:
> {code}
> interface Alpha {
> abstract void m()
> }
> class Foo implements Alpha {
> void m() { println 'foo' }
> }
> class Bar implements Alpha {
> void m() { println 'bar' }
> }
> List list = [new Foo(), new Bar()]
> def hooks = []
> for( def item : list ) {
> hooks.add { item.m() }
> }
> hooks.each { it.call() }
> {code}
> It prints
> {code}
> bar
> bar
> {code}
> Replacing the `for` iterator with a `for( int i=0; etc ) .. ` prints
> correctly:
> {code}
> foo
> bar
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-7409) Closure reference a wrong object when is defining inside an iterator
[
https://issues.apache.org/jira/browse/GROOVY-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722075#comment-16722075
]
Daniel Sun commented on GROOVY-7409:
We can close it now?
> Closure reference a wrong object when is defining inside an iterator
> -
>
> Key: GROOVY-7409
> URL: https://issues.apache.org/jira/browse/GROOVY-7409
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.3.11, 2.4.3
>Reporter: paolo di tommaso
>Priority: Critical
>
> A closure defined inside an iterator containing a reference to the iterating
> item resolves a wrong object instance.
> To reproduce the error take in consideration the following snippet:
> {code}
> interface Alpha {
> abstract void m()
> }
> class Foo implements Alpha {
> void m() { println 'foo' }
> }
> class Bar implements Alpha {
> void m() { println 'bar' }
> }
> List list = [new Foo(), new Bar()]
> def hooks = []
> for( def item : list ) {
> hooks.add { item.m() }
> }
> hooks.each { it.call() }
> {code}
> It prints
> {code}
> bar
> bar
> {code}
> Replacing the `for` iterator with a `for( int i=0; etc ) .. ` prints
> correctly:
> {code}
> foo
> bar
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8721) Compiling >5k line project with existing output folder with class files in it fails to compile
[
https://issues.apache.org/jira/browse/GROOVY-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722073#comment-16722073
]
Daniel Sun commented on GROOVY-8721:
Could you provide any sample code to reproduce the issue?
> Compiling >5k line project with existing output folder with class files in it
> fails to compile
> --
>
> Key: GROOVY-8721
> URL: https://issues.apache.org/jira/browse/GROOVY-8721
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10 x64
>Reporter: death lord
>Priority: Blocker
>
> Update: Just found out this doesn't happen if you recompile the same 1 file
> every time
> I'm trying to run my project in IntelliJ IDEA and I have to rebuild every
> time or I get this error instead. This wasn't the case in 2.4.12. I can't
> exactly give the project but I can give the stacktrace.
> {code:java}
> Error:Groovyc: While compiling Kismet: BUG! exception in phase 'class
> generation' in source unit '' JVM class can't be loaded for
>
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:88)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:176)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1359)
> at
> org.codehaus.groovy.classgen.asm.BytecodeHelper.getClassInternalName(BytecodeHelper.java:63)
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.evaluateInstanceof(BinaryExpressionHelper.java:644)
> at
> org.codehaus.groovy.classgen.asm.BinaryExpressionHelper.eval(BinaryExpressionHelper.java:275)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:707)
> at
> org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:51)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBooleanExpression(AsmClassGenerator.java:829)
> at
> org.codehaus.groovy.ast.expr.BooleanExpression.visit(BooleanExpression.java:42)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeIfElse(StatementWriter.java:292)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitIfElse(AsmClassGenerator.java:651)
> at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:43)
> at
> org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:93)
> at
> org.codehaus.groovy.classgen.asm.sc.StaticTypesStatementWriter.writeBlockStatement(StaticTypesStatementWriter.java:82)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:635)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:110)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:121)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:495)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:431)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:132)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:576)
> at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1103)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
> at
> org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:269)
> at
> org.codehaus.groovy.control.CompilationUnit$18.call(CompilationUnit.java:850)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
> at
> org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
> at
> org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:115)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
>
