[jira] [Resolved] (GROOVY-8593) DocGenerator could be moved to avoid split packages - part (1)

2018-05-23 Thread Paul King (JIRA)

 [ 
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)

2018-05-23 Thread Paul King (JIRA)

 [ 
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

2018-05-23 Thread asfgit
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 ...

2018-05-23 Thread danielsun1106
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

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
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 ...

2018-05-23 Thread danielsun1106
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...

2018-05-23 Thread asfgit
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)

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
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)

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
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 ...

2018-05-23 Thread asfgit
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'

2018-05-23 Thread Paul King (JIRA)

 [ 
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'

2018-05-23 Thread Paul King (JIRA)

 [ 
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'

2018-05-23 Thread Paul King (JIRA)

 [ 
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

2018-05-23 Thread Michael Arndt (JIRA)

[ 
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'

2018-05-23 Thread Alexsey Konstantinov (JIRA)
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

2018-05-23 Thread melix
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 Champeau 
Date:   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

2018-05-23 Thread Daniel Sun (JIRA)

 [ 
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

2018-05-23 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-05-23 Thread asfgit
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

2018-05-23 Thread Daniel Sun (JIRA)
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

2018-05-23 Thread danielsun1106
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 Sun 
Date:   2018-05-23T09:26:16Z

Bump ivy to 2.5.0-rc1




---


[GitHub] groovy pull request #717: Groovy 8562 wrong closure delegation for property ...

2018-05-23 Thread MeneDev
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: Mene 
Date:   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

2018-05-23 Thread Daniel Sun (JIRA)

 [ 
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

2018-05-23 Thread Daniel Sun (JIRA)
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)