[jira] [Resolved] (GROOVY-8593) DocGenerator could be moved to avoid split packages - part (1)
[ https://issues.apache.org/jira/browse/GROOVY-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8593. --- Resolution: Fixed Fix Version/s: 2.5.0 > DocGenerator could be moved to avoid split packages - part (1) > -- > > Key: GROOVY-8593 > URL: https://issues.apache.org/jira/browse/GROOVY-8593 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.5.0 > > > Intended to be a two step process. > (1) move it to the new package but leave behind a @Deprecated delegating > skeleton file in the old location > (2) remove the deprecated file in a future release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8594) DocGenerator could be moved to avoid split packages - part (2)
[ https://issues.apache.org/jira/browse/GROOVY-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8594. --- Resolution: Fixed Fix Version/s: 3.0.0-alpha-3 2.6.0-alpha-4 > DocGenerator could be moved to avoid split packages - part (2) > -- > > Key: GROOVY-8594 > URL: https://issues.apache.org/jira/browse/GROOVY-8594 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 > > > Intended to be a two step process. > (1) move it to the new package but leave behind a @Deprecated delegating > skeleton file in the old location > (2) remove the deprecated file in a future release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #719: Optimize generation of Groovydoc
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/719 ---
[GitHub] groovy pull request #717: Groovy 8562 wrong closure delegation for property ...
Github user danielsun1106 commented on a diff in the pull request: https://github.com/apache/groovy/pull/717#discussion_r190359768 --- Diff: src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java --- @@ -596,6 +597,26 @@ public void visitVariableExpression(VariableExpression vexp) { } else if (accessedVariable instanceof FieldNode) { FieldNode fieldNode = (FieldNode) accessedVariable; +TypeCheckingContext.EnclosingClosure enclosingClosure = typeCheckingContext.getEnclosingClosure(); +if (enclosingClosure != null) { +// GROOVY-8562 +// when vexp has the same name as a property of the owner, +// the IMPLICIT_RECEIVER must be set in case it's the delegate +if (tryVariableExpressionAsProperty(vexp, vexp.getName())) { +// IMPLICIT_RECEIVER is handled elsewhere +// however other access needs to be fixed for private access +if (vexp.getNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER) == null) { +boolean lhsOfEnclosingAssignment = isLHSOfEnclosingAssignment(vexp); +ClassNode owner = (ClassNode) vexp.getNodeMetaData(StaticCompilationMetadataKeys.PROPERTY_OWNER); +if (owner != null) { +fieldNode = owner.getField(vexp.getName()); +vexp.setAccessedVariable(fieldNode); +checkOrMarkPrivateAccess(vexp, fieldNode, lhsOfEnclosingAssignment); --- End diff -- `lhsOfEnclosingAssignment` is only used here(in the `if` block) ---
[jira] [Commented] (GROOVY-8562) Wrong Closure delegation for property access when using @CompileStatic and DELEGATE_FIRST / DELEGATE_ONLY
[ https://issues.apache.org/jira/browse/GROOVY-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487836#comment-16487836 ] ASF GitHub Bot commented on GROOVY-8562: Github user danielsun1106 commented on a diff in the pull request: https://github.com/apache/groovy/pull/717#discussion_r190359768 --- Diff: src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java --- @@ -596,6 +597,26 @@ public void visitVariableExpression(VariableExpression vexp) { } else if (accessedVariable instanceof FieldNode) { FieldNode fieldNode = (FieldNode) accessedVariable; +TypeCheckingContext.EnclosingClosure enclosingClosure = typeCheckingContext.getEnclosingClosure(); +if (enclosingClosure != null) { +// GROOVY-8562 +// when vexp has the same name as a property of the owner, +// the IMPLICIT_RECEIVER must be set in case it's the delegate +if (tryVariableExpressionAsProperty(vexp, vexp.getName())) { +// IMPLICIT_RECEIVER is handled elsewhere +// however other access needs to be fixed for private access +if (vexp.getNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER) == null) { +boolean lhsOfEnclosingAssignment = isLHSOfEnclosingAssignment(vexp); +ClassNode owner = (ClassNode) vexp.getNodeMetaData(StaticCompilationMetadataKeys.PROPERTY_OWNER); +if (owner != null) { +fieldNode = owner.getField(vexp.getName()); +vexp.setAccessedVariable(fieldNode); +checkOrMarkPrivateAccess(vexp, fieldNode, lhsOfEnclosingAssignment); --- End diff -- `lhsOfEnclosingAssignment` is only used here(in the `if` block) > Wrong Closure delegation for property access when using @CompileStatic and > DELEGATE_FIRST / DELEGATE_ONLY > - > > Key: GROOVY-8562 > URL: https://issues.apache.org/jira/browse/GROOVY-8562 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.3.11, 2.6.0-alpha-3, 3.0.0-alpha-2, 2.5.0-rc-1, 2.4.15 >Reporter: Michael Arndt >Priority: Major > > Closures resolve to owner property although `DELEGATE_FIRST` or > `DELEGATE_ONLY` are set as `resolveStrategy`. > This only happens when `@CompileStatic` is used. > This does not apply to method calls. > For Groovy 2.3.11 this only affects read operations. > Only the versions 2.5.0-rc-1, 2.4.15, 2.3.11 have been tested yet. > I will add tests for newer versions, but this requires a different test > framework than Spock. > I have created a demo project at > [https://github.com/MeneDev/groovy-bugreport-closure-strategy] > > {code:java} > class ADelegate { > def x = "delegate" > } > @CompileStatic > class AClass { > public T closureExecuter( > ADelegate d, > @DelegatesTo(value = ADelegate, strategy = DELEGATE_ONLY) > Closure c) { > c.resolveStrategy = DELEGATE_ONLY > c.delegate = d > return c() > } > def x = "owner" > > def test() { > def theDelegate = new ADelegate() > def res = closureExecuter(theDelegate) { > return x > } > > // is "owner" instead of "delegate" > return res > } > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8562) Wrong Closure delegation for property access when using @CompileStatic and DELEGATE_FIRST / DELEGATE_ONLY
[ https://issues.apache.org/jira/browse/GROOVY-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487831#comment-16487831 ] ASF GitHub Bot commented on GROOVY-8562: Github user danielsun1106 commented on a diff in the pull request: https://github.com/apache/groovy/pull/717#discussion_r190359237 --- Diff: src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java --- @@ -596,6 +597,26 @@ public void visitVariableExpression(VariableExpression vexp) { } else if (accessedVariable instanceof FieldNode) { FieldNode fieldNode = (FieldNode) accessedVariable; +TypeCheckingContext.EnclosingClosure enclosingClosure = typeCheckingContext.getEnclosingClosure(); +if (enclosingClosure != null) { +// GROOVY-8562 +// when vexp has the same name as a property of the owner, +// the IMPLICIT_RECEIVER must be set in case it's the delegate +if (tryVariableExpressionAsProperty(vexp, vexp.getName())) { +// IMPLICIT_RECEIVER is handled elsewhere +// however other access needs to be fixed for private access +if (vexp.getNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER) == null) { +boolean lhsOfEnclosingAssignment = isLHSOfEnclosingAssignment(vexp); --- End diff -- `lhsOfEnclosingAssignment` seems to be able to inline > Wrong Closure delegation for property access when using @CompileStatic and > DELEGATE_FIRST / DELEGATE_ONLY > - > > Key: GROOVY-8562 > URL: https://issues.apache.org/jira/browse/GROOVY-8562 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.3.11, 2.6.0-alpha-3, 3.0.0-alpha-2, 2.5.0-rc-1, 2.4.15 >Reporter: Michael Arndt >Priority: Major > > Closures resolve to owner property although `DELEGATE_FIRST` or > `DELEGATE_ONLY` are set as `resolveStrategy`. > This only happens when `@CompileStatic` is used. > This does not apply to method calls. > For Groovy 2.3.11 this only affects read operations. > Only the versions 2.5.0-rc-1, 2.4.15, 2.3.11 have been tested yet. > I will add tests for newer versions, but this requires a different test > framework than Spock. > I have created a demo project at > [https://github.com/MeneDev/groovy-bugreport-closure-strategy] > > {code:java} > class ADelegate { > def x = "delegate" > } > @CompileStatic > class AClass { > public T closureExecuter( > ADelegate d, > @DelegatesTo(value = ADelegate, strategy = DELEGATE_ONLY) > Closure c) { > c.resolveStrategy = DELEGATE_ONLY > c.delegate = d > return c() > } > def x = "owner" > > def test() { > def theDelegate = new ADelegate() > def res = closureExecuter(theDelegate) { > return x > } > > // is "owner" instead of "delegate" > return res > } > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #717: Groovy 8562 wrong closure delegation for property ...
Github user danielsun1106 commented on a diff in the pull request: https://github.com/apache/groovy/pull/717#discussion_r190359237 --- Diff: src/main/java/org/codehaus/groovy/transform/stc/StaticTypeCheckingVisitor.java --- @@ -596,6 +597,26 @@ public void visitVariableExpression(VariableExpression vexp) { } else if (accessedVariable instanceof FieldNode) { FieldNode fieldNode = (FieldNode) accessedVariable; +TypeCheckingContext.EnclosingClosure enclosingClosure = typeCheckingContext.getEnclosingClosure(); +if (enclosingClosure != null) { +// GROOVY-8562 +// when vexp has the same name as a property of the owner, +// the IMPLICIT_RECEIVER must be set in case it's the delegate +if (tryVariableExpressionAsProperty(vexp, vexp.getName())) { +// IMPLICIT_RECEIVER is handled elsewhere +// however other access needs to be fixed for private access +if (vexp.getNodeMetaData(StaticTypesMarker.IMPLICIT_RECEIVER) == null) { +boolean lhsOfEnclosingAssignment = isLHSOfEnclosingAssignment(vexp); --- End diff -- `lhsOfEnclosingAssignment` seems to be able to inline ---
[GitHub] groovy pull request #716: GROOVY-8596: SqlGroovyMethods could be moved to av...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/716 ---
[jira] [Commented] (GROOVY-8596) SqlGroovyMethods could be moved to avoid split packages - part (1)
[ https://issues.apache.org/jira/browse/GROOVY-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487377#comment-16487377 ] ASF GitHub Bot commented on GROOVY-8596: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/716 > SqlGroovyMethods could be moved to avoid split packages - part (1) > -- > > Key: GROOVY-8596 > URL: https://issues.apache.org/jira/browse/GROOVY-8596 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Priority: Major > > Intended to be a two step process. > (1) move it to the new package but leave behind a @Deprecated delegating > skeleton file in the old location > (2) remove the deprecated file in a future release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8593) DocGenerator could be moved to avoid split packages - part (1)
[ https://issues.apache.org/jira/browse/GROOVY-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487369#comment-16487369 ] ASF GitHub Bot commented on GROOVY-8593: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/715 > DocGenerator could be moved to avoid split packages - part (1) > -- > > Key: GROOVY-8593 > URL: https://issues.apache.org/jira/browse/GROOVY-8593 > Project: Groovy > Issue Type: Improvement >Reporter: Paul King >Assignee: Paul King >Priority: Major > > Intended to be a two step process. > (1) move it to the new package but leave behind a @Deprecated delegating > skeleton file in the old location > (2) remove the deprecated file in a future release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #715: GROOVY-8593: DocGenerator could be moved to avoid ...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/715 ---
[jira] [Updated] (GROOVY-8600) BUG! exception in phase 'instruction selection'
[ https://issues.apache.org/jira/browse/GROOVY-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8600: -- Fix Version/s: 2.5.0 > BUG! exception in phase 'instruction selection' > --- > > Key: GROOVY-8600 > URL: https://issues.apache.org/jira/browse/GROOVY-8600 > Project: Groovy > Issue Type: Bug > Components: class generator >Affects Versions: 2.4.15 > Environment: Windows 10, IntelliJ IDEA 2018.1.3, > org.codehaus.groovy:groovy-all:2.4.15 >Reporter: Alexsey Konstantinov >Assignee: Paul King >Priority: Major > Fix For: 2.4.16, 2.5.0 > > > An error occurred when compiling a class of this construction: > {code} > import groovy.transform.CompileStatic > class TestCompileStatic { > Closure func > @CompileStatic > void testCallFunc () { > {color:#d04437}if (func != null) func('test'){color} > } > } > {code} > > BUG! exception in phase 'instruction selection' in source unit > > 'TestCompileStatic.groovy' unexpected NullpointerException > if you change the code to this: > {{{color:#8eb021}if (func != null) func.call('test'){color}}} > then the class is compiled correctly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GROOVY-8600) BUG! exception in phase 'instruction selection'
[ https://issues.apache.org/jira/browse/GROOVY-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8600. --- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.4.16 That error message should no longer occur. Thanks for reporting the issue. > BUG! exception in phase 'instruction selection' > --- > > Key: GROOVY-8600 > URL: https://issues.apache.org/jira/browse/GROOVY-8600 > Project: Groovy > Issue Type: Bug > Components: class generator >Affects Versions: 2.4.15 > Environment: Windows 10, IntelliJ IDEA 2018.1.3, > org.codehaus.groovy:groovy-all:2.4.15 >Reporter: Alexsey Konstantinov >Assignee: Paul King >Priority: Major > Fix For: 2.4.16 > > > An error occurred when compiling a class of this construction: > {code} > import groovy.transform.CompileStatic > class TestCompileStatic { > Closure func > @CompileStatic > void testCallFunc () { > {color:#d04437}if (func != null) func('test'){color} > } > } > {code} > > BUG! exception in phase 'instruction selection' in source unit > > 'TestCompileStatic.groovy' unexpected NullpointerException > if you change the code to this: > {{{color:#8eb021}if (func != null) func.call('test'){color}}} > then the class is compiled correctly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8600) BUG! exception in phase 'instruction selection'
[ https://issues.apache.org/jira/browse/GROOVY-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8600: -- Description: An error occurred when compiling a class of this construction: {code} import groovy.transform.CompileStatic class TestCompileStatic { Closure func @CompileStatic void testCallFunc () { {color:#d04437}if (func != null) func('test'){color} } } {code} > BUG! exception in phase 'instruction selection' in source unit > 'TestCompileStatic.groovy' unexpected NullpointerException if you change the code to this: {{{color:#8eb021}if (func != null) func.call('test'){color}}} then the class is compiled correctly was: An error occurred when compiling a class of this construction: {{import groovy.transform.CompileStatic}} {{class TestCompileStatic {}} {{ Closure func}} {{ @CompileStatic}} {{ void testCallFunc () {}} {{ {color:#d04437}if (func != null) func('test'){color}}} {{ }}} {{}}} > BUG! exception in phase 'instruction selection' in source unit > 'TestCompileStatic.groovy' unexpected NullpointerException if you change the code to this: {{{color:#8eb021}if (func != null) func.call('test'){color}}} then the class is compiled correctly > BUG! exception in phase 'instruction selection' > --- > > Key: GROOVY-8600 > URL: https://issues.apache.org/jira/browse/GROOVY-8600 > Project: Groovy > Issue Type: Bug > Components: class generator >Affects Versions: 2.4.15 > Environment: Windows 10, IntelliJ IDEA 2018.1.3, > org.codehaus.groovy:groovy-all:2.4.15 >Reporter: Alexsey Konstantinov >Priority: Major > > An error occurred when compiling a class of this construction: > {code} > import groovy.transform.CompileStatic > class TestCompileStatic { > Closure func > @CompileStatic > void testCallFunc () { > {color:#d04437}if (func != null) func('test'){color} > } > } > {code} > > BUG! exception in phase 'instruction selection' in source unit > > 'TestCompileStatic.groovy' unexpected NullpointerException > if you change the code to this: > {{{color:#8eb021}if (func != null) func.call('test'){color}}} > then the class is compiled correctly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8562) Wrong Closure delegation for property access when using @CompileStatic and DELEGATE_FIRST / DELEGATE_ONLY
[ https://issues.apache.org/jira/browse/GROOVY-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487160#comment-16487160 ] Michael Arndt commented on GROOVY-8562: --- PR is open https://github.com/apache/groovy/pull/717 > Wrong Closure delegation for property access when using @CompileStatic and > DELEGATE_FIRST / DELEGATE_ONLY > - > > Key: GROOVY-8562 > URL: https://issues.apache.org/jira/browse/GROOVY-8562 > Project: Groovy > Issue Type: Bug > Components: Static compilation >Affects Versions: 2.3.11, 2.6.0-alpha-3, 3.0.0-alpha-2, 2.5.0-rc-1, 2.4.15 >Reporter: Michael Arndt >Priority: Major > > Closures resolve to owner property although `DELEGATE_FIRST` or > `DELEGATE_ONLY` are set as `resolveStrategy`. > This only happens when `@CompileStatic` is used. > This does not apply to method calls. > For Groovy 2.3.11 this only affects read operations. > Only the versions 2.5.0-rc-1, 2.4.15, 2.3.11 have been tested yet. > I will add tests for newer versions, but this requires a different test > framework than Spock. > I have created a demo project at > [https://github.com/MeneDev/groovy-bugreport-closure-strategy] > > {code:java} > class ADelegate { > def x = "delegate" > } > @CompileStatic > class AClass { > public T closureExecuter( > ADelegate d, > @DelegatesTo(value = ADelegate, strategy = DELEGATE_ONLY) > Closure c) { > c.resolveStrategy = DELEGATE_ONLY > c.delegate = d > return c() > } > def x = "owner" > > def test() { > def theDelegate = new ADelegate() > def res = closureExecuter(theDelegate) { > return x > } > > // is "owner" instead of "delegate" > return res > } > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8600) BUG! exception in phase 'instruction selection'
Alexsey Konstantinov created GROOVY-8600: Summary: BUG! exception in phase 'instruction selection' Key: GROOVY-8600 URL: https://issues.apache.org/jira/browse/GROOVY-8600 Project: Groovy Issue Type: Bug Components: class generator Affects Versions: 2.4.15 Environment: Windows 10, IntelliJ IDEA 2018.1.3, org.codehaus.groovy:groovy-all:2.4.15 Reporter: Alexsey Konstantinov An error occurred when compiling a class of this construction: {{import groovy.transform.CompileStatic}} {{class TestCompileStatic {}} {{ Closure func}} {{ @CompileStatic}} {{ void testCallFunc () {}} {{ {color:#d04437}if (func != null) func('test'){color}}} {{ }}} {{}}} > BUG! exception in phase 'instruction selection' in source unit > 'TestCompileStatic.groovy' unexpected NullpointerException if you change the code to this: {{{color:#8eb021}if (func != null) func.call('test'){color}}} then the class is compiled correctly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #719: Optimize generation of Groovydoc
GitHub user melix opened a pull request: https://github.com/apache/groovy/pull/719 Optimize generation of Groovydoc There's a lot to say about Groovydoc, but worst of all, its performance is terrible. This PR is an attempt to fix part of it. Before my changes: https://scans.gradle.com/s/msfs2nf5mqmxw (3m35s) After my changes: https://scans.gradle.com/s/a7pi5g6bb7bbu (53s) @paulk-asert I'm leaving the review/merge to you as I spent already too much time on this. Given the improvements, I wouldn't mind a backport to 2.5! You can merge this pull request into a Git repository by running: $ git pull https://github.com/melix/groovy cc/faster-groovydoc Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/719.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #719 commit 3a8dd6d5b3f36e7058567f32264ce9c3126e3631 Author: Cedric ChampeauDate: 2018-05-23T06:34:10Z Cache class resolution As soon as we have a project with a reasonable size, we spend a large amount of time resolving the same classes again and again. This commit introduces a (poor man's) cache to avoid the same lookups. It's not an attempt to make Groovydoc better, it's just a patch to make it not so slow. commit d8f4ec430f1285c36375047b0f3488a313602555 Author: Cedric Champeau Date: 2018-05-23T06:35:41Z Use a reasonable size buffer for generated docs The default buffer is a 16(!) characters string. Most of the groovydoc files we generate are over 10k, so this commit adds a reasonable size buffer for templates, which avoids a lot of buffer resizes. commit c5832093ff9992537db1856b7f0dae58e9fe0081 Author: Cedric Champeau Date: 2018-05-23T07:49:38Z Perform direct lookup in maps Why the h... we were iterating over the map to check each entry is beyond my understanding. commit af7605f5ff84cb7a381696fb0d3da8c4902ff658 Author: Cedric Champeau Date: 2018-05-23T07:59:59Z Implement a bit smarter lookup The code isn't really clear what the inputs/outputs are, so it's just reordering things to make it faster. commit f810c805922155988395ee1f996530987b0b71f6 Author: Cedric Champeau Date: 2018-05-23T09:03:47Z Optimize StringBuilder#leftShift for GString case commit a5c49a01678fe13145c8e32b415f68361544d06b Author: Cedric Champeau Date: 2018-05-23T09:42:42Z Don't use exception for control flow It's extremely slow, as we generate tons of stacktraces for nothing! commit 12d375852d0c83b5e5924a12d09af6035496aaa2 Author: Cedric Champeau Date: 2018-05-23T09:58:11Z Cache classNamed lookups The calls to `substring` are pretty expensive and done again and again on the same classes. This is extremely inefficient, so this commit adds an adhoc cache for this. Note that the relativeness to GroovyClassDoc seems related to a poorly designed modeled, it can certainly be even faster. commit 45e3225485ef44385ff7aa3759c2c63932e088f2 Author: Cedric Champeau Date: 2018-05-23T10:03:18Z Precompile some regular expressions commit 31c93d6755814953e6eb0e92875ffafb8d33b060 Author: Cedric Champeau Date: 2018-05-23T10:12:21Z Cache external class lookup ---
[jira] [Resolved] (GROOVY-8599) Bump ivy to 2.5.0-rc1
[ https://issues.apache.org/jira/browse/GROOVY-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-8599. Resolution: Fixed Fixed by https://github.com/apache/groovy/commit/5eab4a5ffbc2e28c442f3e1467f4112b892e6072 > Bump ivy to 2.5.0-rc1 > - > > Key: GROOVY-8599 > URL: https://issues.apache.org/jira/browse/GROOVY-8599 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GROOVY-8599) Bump ivy to 2.5.0-rc1
[ https://issues.apache.org/jira/browse/GROOVY-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487059#comment-16487059 ] ASF GitHub Bot commented on GROOVY-8599: Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/718 > Bump ivy to 2.5.0-rc1 > - > > Key: GROOVY-8599 > URL: https://issues.apache.org/jira/browse/GROOVY-8599 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #718: GROOVY-8599: Bump ivy to 2.5.0-rc1
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/718 ---
[jira] [Created] (GROOVY-8599) Bump ivy to 2.5.0-rc1
Daniel Sun created GROOVY-8599: -- Summary: Bump ivy to 2.5.0-rc1 Key: GROOVY-8599 URL: https://issues.apache.org/jira/browse/GROOVY-8599 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #718: Bump ivy to 2.5.0-rc1
GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/718 Bump ivy to 2.5.0-rc1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy bump-ivy-2.5.0-rc1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/718.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #718 commit 47a19330a0afa4d03da67f92eb89edab517a0e16 Author: Daniel SunDate: 2018-05-23T09:26:16Z Bump ivy to 2.5.0-rc1 ---
[GitHub] groovy pull request #717: Groovy 8562 wrong closure delegation for property ...
GitHub user MeneDev opened a pull request: https://github.com/apache/groovy/pull/717 Groovy 8562 wrong closure delegation for property access and compile static Roundup: The StaticTypeCheckingVisitor would not look consider FieldNode to potentially delegate to a different Field. I think this could only occur for name collisions, i.e. the owner has a field with the same name as the delegate. Calling tryVariableExpressionAsProperty solved this, however this broke other tests. To solve this I cheked IMPLICIT_RECEIVER, if unset and PROPERTY_OWNER is present, checkOrMarkPrivateAccess must be called to ensure the accessors are generated. The VariableExpressionTransformer ignored delegation metadata when a private field accessor was present. I inversed that logic to give delegation metadata precedence over private field accessors. Build passes https://travis-ci.org/MeneDev/groovy/builds/382561549 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MeneDev/groovy GROOVY-8562_WrongClosureDelegationForPropertyAccessAndCompileStatic Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/717.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #717 commit 0a47728777a15bfa986b89da7495c858396e737f Author: MeneDate: 2018-05-16T18:28:13Z Add first test case for GROOVY-8562 / first partial but destructive fix commit 72a08191b525fdf48daca3a72b89b410fb9e Author: Mene Date: 2018-05-16T18:36:44Z Add problem from jhunovis / slack https://groovy-community.slack.com/files/U9CM8G6AJ/FAR1PJT1U/behavior_of__with__and___compilestatic.groovy commit 2930639fc2e25250d72f070091a9f996befcf9e4 Author: Mene Date: 2018-05-17T17:03:31Z Fix first test case for GROOVY-8562 without breaking other tests commit 5b73488561641cc5b94b4642f126c216675e2040 Author: Mene Date: 2018-05-17T17:44:40Z Add missing tests from GROOVY-8562 / remove unrelated tests commit 77ee4d4cda14e09288aceec422d9683bab103c56 Author: Mene Date: 2018-05-22T17:55:24Z Fix writing for GROOVY-8562 Call tryTransformDelegateToProperty first then tryTransformDelegateToProperty commit 8f833d3e322339e66cd8e18f90d1a7b4a10fa6ca Author: Mene Date: 2018-05-23T08:43:06Z Add Test from groovy slack for GROOVY-8562 ---
[jira] [Resolved] (GROOVY-8598) Possible bug in AstBuilder Antlr4
[ https://issues.apache.org/jira/browse/GROOVY-8598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-8598. Resolution: Fixed Fixed by https://github.com/apache/groovy/commit/a26c190f9a70b0c430004d80c56e37703c2edfe8 > Possible bug in AstBuilder Antlr4 > - > > Key: GROOVY-8598 > URL: https://issues.apache.org/jira/browse/GROOVY-8598 > Project: Groovy > Issue Type: Bug > Components: parser-antlr4 >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 > > > From dev mailing > list(http://groovy.329449.n5.nabble.com/Possible-bug-in-AstBuilder-Antlr4-tt5750881.html): > > Hi Daniel, > I think I have found a bug in the antlr4 AstBuilder class. > Add this line: > import groovy.transform.CompileStatic > before this one in a GString template: > [https://github.com/melix/groovy-core/blob/d9656842908acb403599cf574f509aea2737be47/subprojects/groovy-groovydoc/src/main/resources/org/codehaus/groovy/tools/groovydoc/gstringTemplates/classLevel/classDocName.html#L27] > And run GroovyDocToolTest. Some tests will fail with: > java.lang.ClassCastException: org.codehaus.groovy.ast.ImportNode cannot be > cast to org.codehaus.groovy.ast.stmt.Statement > at > org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatement(AstBuilder.java:4074) > at > java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at > java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at > java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) > at > org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatements(AstBuilder.java:4058) > at > org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatementsOpt(AstBuilder.java:4045) > at > org.apache.groovy.parser.antlr4.AstBuilder.visitClosure(AstBuilder.java:3715) > at > org.apache.groovy.parser.antlr4.AstBuilder.visitClosurePrmrAlt(AstBuilder.java:3120) > at > org.apache.groovy.parser.antlr4.AstBuilder.visitClosurePrmrAlt(AstBuilder.java:356) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GROOVY-8598) Possible bug in AstBuilder Antlr4
Daniel Sun created GROOVY-8598: -- Summary: Possible bug in AstBuilder Antlr4 Key: GROOVY-8598 URL: https://issues.apache.org/jira/browse/GROOVY-8598 Project: Groovy Issue Type: Bug Components: parser-antlr4 Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3 >From dev mailing >list(http://groovy.329449.n5.nabble.com/Possible-bug-in-AstBuilder-Antlr4-tt5750881.html): Hi Daniel, I think I have found a bug in the antlr4 AstBuilder class. Add this line: import groovy.transform.CompileStatic before this one in a GString template: [https://github.com/melix/groovy-core/blob/d9656842908acb403599cf574f509aea2737be47/subprojects/groovy-groovydoc/src/main/resources/org/codehaus/groovy/tools/groovydoc/gstringTemplates/classLevel/classDocName.html#L27] And run GroovyDocToolTest. Some tests will fail with: java.lang.ClassCastException: org.codehaus.groovy.ast.ImportNode cannot be cast to org.codehaus.groovy.ast.stmt.Statement at org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatement(AstBuilder.java:4074) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) at org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatements(AstBuilder.java:4058) at org.apache.groovy.parser.antlr4.AstBuilder.visitBlockStatementsOpt(AstBuilder.java:4045) at org.apache.groovy.parser.antlr4.AstBuilder.visitClosure(AstBuilder.java:3715) at org.apache.groovy.parser.antlr4.AstBuilder.visitClosurePrmrAlt(AstBuilder.java:3120) at org.apache.groovy.parser.antlr4.AstBuilder.visitClosurePrmrAlt(AstBuilder.java:356) -- This message was sent by Atlassian JIRA (v7.6.3#76005)