[GitHub] [groovy] danielsun1106 edited a comment on pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
danielsun1106 edited a comment on pull request #1278: URL: https://github.com/apache/groovy/pull/1278#issuecomment-643707171 As you can find, most of groovy options are short, e.g. `groovy.antlr4`, `groovy.target.indy`, etc. `groovy.generate.stub.in.memory` is too long to remember and hard to use, so it's better to shorten it and make it friendly to users. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
danielsun1106 commented on pull request #1278: URL: https://github.com/apache/groovy/pull/1278#issuecomment-643707171 As you can find, most of groovy options are short, e.g. `groovy.antlr4`, `groovy.target.indy`, etc. `groovy.generate.stub.in.memory` is too long to remember and hard to use, it's better to shorten it and make it friendly to users. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
eric-milles commented on pull request #1278: URL: https://github.com/apache/groovy/pull/1278#issuecomment-643705948 Necessary is probably a bit strong. Why does the system property name need to be changed? If not removing, why change? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
danielsun1106 commented on pull request #1278: URL: https://github.com/apache/groovy/pull/1278#issuecomment-643705171 As a normal groovy user, we run/compile Groovy code via command line, so the JVM option is still necessary for us. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] eric-milles commented on pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
eric-milles commented on pull request #1278: URL: https://github.com/apache/groovy/pull/1278#issuecomment-643704453 Do you need a system property any more? For each option that is available to be set on compiler config, why does each also require a system property? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 opened a new pull request #1278: GROOVY-9592: Replace "groovy.generate.stub.in.memory" with "groovy.me…
danielsun1106 opened a new pull request #1278: URL: https://github.com/apache/groovy/pull/1278 …m.stub" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
*P.S.*
* Antlr2 can prompt missing right parethesis smartly without any error
alternative, but antlr4 can not.
* Parsing all groovy source code of nextflow[2] sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s, about 33% time
reduced. Here is the script to measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
[2] https://github.com/nextflow-io/nextflow
was:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow[2] sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s, about 33% time
reduced. Here is the code to measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
[2] https://github.com/nextflow-io/nextflow
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the antlr2 parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source
[jira] [Created] (GROOVY-9592) Replace "groovy.generate.stub.in.memory" with "groovy.mem.stub"
Daniel Sun created GROOVY-9592:
--
Summary: Replace "groovy.generate.stub.in.memory" with
"groovy.mem.stub"
Key: GROOVY-9592
URL: https://issues.apache.org/jira/browse/GROOVY-9592
Project: Groovy
Issue Type: Improvement
Reporter: Daniel Sun
Assignee: Daniel Sun
Fix For: 4.0.0-alpha-1, 3.0.5
The JVM option {{groovy.generate.stub.in.memory}} is too long for users to
remember, replace it with {{groovy.mem.stub}}
For Groovy 3, {{groovy.generate.stub.in.memory}} will be deprecated.
Since Groovy 4, {{groovy.generate.stub.in.memory}} will be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9587) Scope of method call changed from non-static to static 2.4->2.5
[
https://issues.apache.org/jira/browse/GROOVY-9587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134980#comment-17134980
]
Eric Milles commented on GROOVY-9587:
-
It should work, I just wanted a bit of info to help understand. PR with fix
has been submitted.
> Scope of method call changed from non-static to static 2.4->2.5
> ---
>
> Key: GROOVY-9587
> URL: https://issues.apache.org/jira/browse/GROOVY-9587
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.12
>Reporter: Eric Helgeson
>Assignee: Eric Milles
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> class Foo {
>static storageProvider
>def getStorageProvider(Boolean a) {
> return storageProvider
>}
>def getStorageProvider() {
> if(!storageProvider) {
>getStorageProvider(true) // <-- Attempts to call statically in 2.5
> }
> return storageProvider
>}
> }
> new Foo().getStorageProvider()
> {code}
> In groovy 2.5+ it seems it gets confused if you have a static variable in a
> class, say static storageProvider, and a non-static method def
> getStorageProvider(Boolean x) it tries to call the getStorageProvider(true)
> statically, which does not exist.
>
> In the groovyConsole you can see the change happen between conversion and
> semantic analysis - it changes from non-static to static.
>
> Unsure this is intended or not. I couldn't find mention of it in any changes.
> It would be nice to document/know why the change happened between 2.4/2.5.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles opened a new pull request #1277: GROOVY-9587: don't check for property for non-empty call args
eric-milles opened a new pull request #1277: URL: https://github.com/apache/groovy/pull/1277 `transformMethodCallExpression` had become very difficult to understand and modify, so I tried to reorganize it, reduce the repetition, and simplify the conditions as best as I could. https://issues.apache.org/jira/browse/GROOVY-9587 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-9587) Scope of method call changed from non-static to static 2.4->2.5
[
https://issues.apache.org/jira/browse/GROOVY-9587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134932#comment-17134932
]
Eric Helgeson commented on GROOVY-9587:
---
> Should "storageProvider" be declared private?
Possibly, it does fix the issue.
> Do you have a concrete example of this I could take a peek at?
In practice It is basically being used to cache a variable on a singleton.
Renaming the variable or adding private is a straight forward fix.
If this is expected then it's fine to close this. I more so wanted to raise the
issue as I didn't understand if it was an expected change or not.
> Scope of method call changed from non-static to static 2.4->2.5
> ---
>
> Key: GROOVY-9587
> URL: https://issues.apache.org/jira/browse/GROOVY-9587
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.5.12
>Reporter: Eric Helgeson
>Assignee: Eric Milles
>Priority: Major
>
>
> {code:java}
> class Foo {
>static storageProvider
>def getStorageProvider(Boolean a) {
> return storageProvider
>}
>def getStorageProvider() {
> if(!storageProvider) {
>getStorageProvider(true) // <-- Attempts to call statically in 2.5
> }
> return storageProvider
>}
> }
> new Foo().getStorageProvider()
> {code}
> In groovy 2.5+ it seems it gets confused if you have a static variable in a
> class, say static storageProvider, and a non-static method def
> getStorageProvider(Boolean x) it tries to call the getStorageProvider(true)
> statically, which does not exist.
>
> In the groovyConsole you can see the change happen between conversion and
> semantic analysis - it changes from non-static to static.
>
> Unsure this is intended or not. I couldn't find mention of it in any changes.
> It would be nice to document/know why the change happened between 2.4/2.5.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] eric-milles opened a new pull request #1276: GROOVY-9591: no error for dynamic variable in closure in static context
eric-milles opened a new pull request #1276: URL: https://github.com/apache/groovy/pull/1276 https://issues.apache.org/jira/browse/GROOVY-9591 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GROOVY-9591) Compiler error for use of variable expression within tap closure
Eric Milles created GROOVY-9591:
---
Summary: Compiler error for use of variable expression within tap
closure
Key: GROOVY-9591
URL: https://issues.apache.org/jira/browse/GROOVY-9591
Project: Groovy
Issue Type: Bug
Affects Versions: 2.5.12, 3.0.4
Reporter: Eric Milles
Assignee: Eric Milles
Consider the following:
{code:groovy}
@groovy.transform.ToString
class A {
A(a) {}
def b
}
class C {
C() {
this(new A(null).tap { b = 42 })
}
C(x) {
print x
}
}
new C() // should output "A(42)"
{code}
A has no default constructor, so properties are initialized in tap closure.
Because the "tap" expression is passed as argument to special constructor call,
extra static checking is performed and the error "Apparent variable 'b' was
found in a static scope but doesn't refer to a local variable, static field or
class." is emitted.
Creation of A cannot be moved to a local variable because special constructor
call must be the first statement/expression in the constructor body.
This was discovered while investigating variations of GROOVY-8327, GROOVY-8389,
and GROOVY-9587.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GROOVY-9590) Bump javaparser to 3.16.1
[ https://issues.apache.org/jira/browse/GROOVY-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Sun resolved GROOVY-9590. Assignee: Daniel Sun Resolution: Fixed > Bump javaparser to 3.16.1 > - > > Key: GROOVY-9590 > URL: https://issues.apache.org/jira/browse/GROOVY-9590 > Project: Groovy > Issue Type: Dependency upgrade >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 4.0.0-alpha-1, 3.0.5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow[2] sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s, about 33% time
reduced. Here is the code to measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
[2] https://github.com/nextflow-io/nextflow
was:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s, about 33% time
reduced. Here is the code to measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the antlr2 parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source code in parallel.
> Use compiler option {{parallelParse}} or
[jira] [Created] (GROOVY-9590) Bump javaparser to 3.16.1
Daniel Sun created GROOVY-9590: -- Summary: Bump javaparser to 3.16.1 Key: GROOVY-9590 URL: https://issues.apache.org/jira/browse/GROOVY-9590 Project: Groovy Issue Type: Dependency upgrade Reporter: Daniel Sun Fix For: 4.0.0-alpha-1, 3.0.5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s, about 33% time
reduced. Here is the code to measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
was:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s. Here is the code to
measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the antlr2 parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source code in parallel.
> Use compiler option {{parallelParse}} or JVM option
> {{groovy.parallel.parse}} to enable/disable the improvement.
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
[https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
*P.S.*
* antlr2 parser can prompt missing right parethesis smartly without any error
alternative
* Parsing all groovy source code of nextflow sequentially costs 64s on my
machine. If {{parallelParse}} is enabled, just costs 43s. Here is the code to
measure the time costed:
{code:java}
import groovy.io.FileType
import org.codehaus.groovy.ast.ModuleNode
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.CompilerConfiguration
import org.codehaus.groovy.control.Phases
def parse(boolean parallelParse) {
def sourceFileList = []
new File('./src').eachFileRecurse (FileType.FILES) { file ->
if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
return
sourceFileList << file
}
long elapsedTimeMillis
new CompilationUnit(new CompilerConfiguration(optimizationOptions:
[parallelParse: parallelParse])).tap {
sourceFileList.each { f ->
addSource f
}
def b = System.currentTimeMillis()
compile Phases.CONVERSION
def e = System.currentTimeMillis()
elapsedTimeMillis = e - b
}
return elapsedTimeMillis
}
// def t = parse(false) // no parallel, costs 64s
def t = parse(true) // in parallel, costs 43s
println "# ${t / 1000}s elapsed"
{code}
was:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
P.S. antlr2 parser can prompt missing right parethesis smartly without any
error alternative
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the antlr2 parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source code in parallel.
> Use compiler option {{parallelParse}} or JVM option
> {{groovy.parallel.parse}} to enable/disable the improvement. For Groovy 3,
> the improvement is disabled by default, but for Groovy 4+, the improvement
> will be enabled.
> [1]
> [https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261]
> *P.S.*
> * antlr2 parser can prompt missing right parethesis smartly without any
> error alternative
> * Parsing all groovy source code of nextflow sequentially costs 64s on my
> machine. If {{parallelParse}} is enabled, just costs 43s. Here is the code to
> measure the time costed:
> {code:java}
> import groovy.io.FileType
> import org.codehaus.groovy.ast.ModuleNode
> import org.codehaus.groovy.control.CompilationUnit
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.Phases
> def parse(boolean parallelParse) {
> def sourceFileList = []
> new File('./src').eachFileRecurse (FileType.FILES) { file ->
> if (!file.name.endsWith('.groovy') && !file.name.endsWith('.gradle'))
> return
>
> sourceFileList << file
> }
> long elapsedTimeMillis
> new CompilationUnit(new CompilerConfiguration(optimizationOptions:
> [parallelParse: parallelParse])).tap {
> sourceFileList.each { f ->
> addSource f
> }
>
> def b = System.currentTimeMillis()
> compile
[GitHub] [groovy] danielsun1106 merged pull request #1267: GROOVY-9344 (part 1): SC: retain closure shared variable metadata for classgen
danielsun1106 merged pull request #1267: URL: https://github.com/apache/groovy/pull/1267 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1267: GROOVY-9344 (part 1): SC: retain closure shared variable metadata for classgen
danielsun1106 commented on pull request #1267: URL: https://github.com/apache/groovy/pull/1267#issuecomment-643624890 Merged. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 merged pull request #1268: GROOVY-7701: do not cast RHS before LHS of assignment is visited
danielsun1106 merged pull request #1268: URL: https://github.com/apache/groovy/pull/1268 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-7701) org.codehaus.groovy.runtime.typehandling.GroovyCastException in Groovy ".with { ... }" - Block
[
https://issues.apache.org/jira/browse/GROOVY-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-7701.
Fix Version/s: 3.0.5
4.0.0-alpha-1
Resolution: Fixed
> org.codehaus.groovy.runtime.typehandling.GroovyCastException in Groovy ".with
> { ... }" - Block
> --
>
> Key: GROOVY-7701
> URL: https://issues.apache.org/jira/browse/GROOVY-7701
> Project: Groovy
> Issue Type: Bug
> Components: groovy-jdk
>Affects Versions: 2.4.3, 2.4.4, 2.4.5
> Environment: all?
> Tested with Ubuntu 14.04.3 LTS (64 Bit) | MacOS 10.11 and Groovy 2.4.5, 2.3.4
>Reporter: Maik Igloffstein
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> {code}
> subClass.with {
> type = ['String']
> }
> {code}
> Should change _SubClass.type_ and not _TopClass.type_.
> The script works fine with _type2_ instead of _type_. Is _type_ a reserved
> word? I can't find any documentation about this.
> h2. Unit-Test / Groovy Console-Test
> {code}
> class SubClass{
> List type
> }
> class TopClass{
> int type = 10
> @Lazy
> List something = {
> List tmp = []
> for(int i = 0; i < 5; i++){
> def subClass = new SubClass()
> subClass.with {
> type = ['String'] // throws
> org.codehaus.groovy.runtime.typehandling.GroovyCastException
> }
> tmp.add(subClass)
> }
> tmp
> }()
> }
> def topClass = new TopClass()
> println GroovySystem.version
> println(topClass.type)
> println(topClass.something)
> println(topClass.type)
> {code}
> h2. Exception
> {code}
> org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast
> object '[String]' with class 'java.util.ArrayList' to class 'int'
> at TopClass$_getSomething_closure1$_closure2.doCall(ConsoleScript3:15)
> at TopClass$_getSomething_closure1.doCall(ConsoleScript3:14)
> at TopClass$_getSomething_closure1.doCall(ConsoleScript3)
> at TopClass.getSomething(ConsoleScript3:11)
> at ConsoleScript3.run(ConsoleScript3:26)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 commented on pull request #1268: GROOVY-7701: do not cast RHS before LHS of assignment is visited
danielsun1106 commented on pull request #1268: URL: https://github.com/apache/groovy/pull/1268#issuecomment-643624640 Merged. Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-8840) CLONE - Compile Static causes getAt to fail (advanced cases)
[
https://issues.apache.org/jira/browse/GROOVY-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-8840.
Fix Version/s: 3.0.5
4.0.0-alpha-1
Resolution: Fixed
> CLONE - Compile Static causes getAt to fail (advanced cases)
>
>
> Key: GROOVY-8840
> URL: https://issues.apache.org/jira/browse/GROOVY-8840
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.4.13, 2.5.0, 3.0.0
> Environment: Intellij plus various versions of Groovy; the same
> problem also occurs in Eclipse-Groovy with the same versions
>Reporter: Jon Kerridge
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I can reproduce by adding @CompileStatic to the example I tried previously
> and can confirm that 2.4.13 is where the regression started. Workaround would
> be to remove @CompileStatic until we can get a fix in place. If you can raise
> a bug issue in Jira, that would be great.
> the reproducer following is a shortened version created by Paul King:
> {code}
> import groovy.transform.CompileStatic
>
> @CompileStatic
> def method() {
> def list = [0, 1, 2, 3]
> for (idx in 1..2) {
> list[idx-1]++
> }
> list
> }
>
> assert method() == [1, 2, 2, 3]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 merged pull request #1272: GROOVY-8840: use inferred type for subscript if operand is placeholder
danielsun1106 merged pull request #1272: URL: https://github.com/apache/groovy/pull/1272 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 commented on pull request #1272: GROOVY-8840: use inferred type for subscript if operand is placeholder
danielsun1106 commented on pull request #1272: URL: https://github.com/apache/groovy/pull/1272#issuecomment-643624473 Merged. Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 merged pull request #1273: GROOVY-7549: STC: if "=" RHS type is inaccessible, revert to origin type
danielsun1106 merged pull request #1273: URL: https://github.com/apache/groovy/pull/1273 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-7549) java.lang.IllegalAccessError occurs when attempting to run code built with CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-7549.
Fix Version/s: 3.0.5
4.0.0-alpha-1
Resolution: Fixed
> java.lang.IllegalAccessError occurs when attempting to run code built with
> CompileStatic
>
>
> Key: GROOVY-7549
> URL: https://issues.apache.org/jira/browse/GROOVY-7549
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.4
>Reporter: Steven Walters
>Assignee: Eric Milles
>Priority: Minor
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Given a small code setup such as the following, where there exists a
> # A publicly declared interface
> # A package private implementation of the interface
> # A static factory class that returns an instance of the implementation *as
> the implementation class*
> {code:title=packa.TheInterface.groovy|borderStyle=solid}
> package packa
> public interface TheInterface {
> public void doStuff()
> }
> {code}
> {code:title=packb.TheImplementation.groovy|borderStyle=solid}
> package packb
> import packa.TheInterface
> @groovy.transform.CompileStatic
> @groovy.transform.PackageScope
> class TheImplementation implements TheInterface {
> public void doStuff() {
> System.out.println("Do some stuff")
> }
> }
> {code}
> {code:title=packb.TheFactory.groovy|borderStyle=solid}
> package packb
> public class TheFactory {
> static TheImplementation getAnInstance() {
> return new TheImplementation()
> }
> }
> {code}
> With CompileStatic, calling the factory method successfully works, but
> calling any method on the returned object fails with
> {{java.lang.IllegalAccessError}}.
> When CompileStatic is removed, the code runs without issue.
> Such as the following.
> {code:title=packa.TheMain.groovy|borderStyle=solid}
> package packa
> import packb.TheFactory
> @groovy.transform.CompileStatic
> public class TheMain {
> public static void main(String[] args) {
> TheInterface if1 = TheFactory.anInstance
> /* the following only fails when CompileStatic is enabled with the
> following error:
> * Exception in thread "main" java.lang.IllegalAccessError: tried to
> access class packb.TheImplementation from class packa.TheMain */
> if1.doStuff()
> }
> }
> {code}
> There seem to be some interesting factors here, as changing the
> {{TheFactory}} to return {{TheInterface}} instead of {{TheImplemenation}}
> also seems to resolve the issue.
> However, changing the return of the {{TheFactory}} is not desirable, as in
> the actual production the above sample was formulated from, there are other
> classes in the {{packb}} package that utilize {{TheFactory}} and should not
> require class casts from {{TheInterface}} to {{TheImplementation}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 commented on pull request #1273: GROOVY-7549: STC: if "=" RHS type is inaccessible, revert to origin type
danielsun1106 commented on pull request #1273: URL: https://github.com/apache/groovy/pull/1273#issuecomment-643624277 Merged. Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (GROOVY-7512) Cannot call Trait method from Closure when using static compilation
[
https://issues.apache.org/jira/browse/GROOVY-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun resolved GROOVY-7512.
Fix Version/s: 3.0.5
4.0.0-alpha-1
Resolution: Fixed
> Cannot call Trait method from Closure when using static compilation
> ---
>
> Key: GROOVY-7512
> URL: https://issues.apache.org/jira/browse/GROOVY-7512
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation, Static Type Checker
>Affects Versions: 2.4.4
>Reporter: César Izurieta
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When running:
> {code:title=test.groovy|borderStyle=solid}
> class X {
> Closure action = {}
> }
> trait T {
> void say(String text) {
> println text
> }
> @groovy.transform.CompileStatic
> X getX() {
> new X(action: {
> say "Hello!"
> })
> }
> }
> class A implements T {
> }
> new A().x.action()
> {code}
> The following exception is thrown:
> {code}
> Caught: java.lang.ClassCastException: java.lang.Class cannot be cast to T
> java.lang.ClassCastException: java.lang.Class cannot be cast to T
> at T$Trait$Helper$_getX_closure1.doCall(test.groovy:14)
> at T$Trait$Helper$_getX_closure1.doCall(test.groovy)
> at test.run(test.groovy:23)
> {code}
> This is only happening on groovy 2.4.4. Removing the static compilation
> annotation or reverting to groovy version 2.4.3 makes the code work.
> The commit that is causing this problem seems to be:
> 1bbed25aa3a08bc0cb7e14e49a1e7c2b82f21a26
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 commented on pull request #1274: GROOVY-7512: add MapStyleConstructorCall override of transformExpression
danielsun1106 commented on pull request #1274: URL: https://github.com/apache/groovy/pull/1274#issuecomment-643623989 Merged. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [groovy] danielsun1106 merged pull request #1274: GROOVY-7512: add MapStyleConstructorCall override of transformExpression
danielsun1106 merged pull request #1274: URL: https://github.com/apache/groovy/pull/1274 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134743#comment-17134743
]
Daniel Sun commented on GROOVY-9209:
Looking forward to [~emilles]'s PR ;-)
> Compiler throws an exception in ClassNode#getTypeClass after checking
> ClassNode#isResolved
> --
>
> Key: GROOVY-9209
> URL: https://issues.apache.org/jira/browse/GROOVY-9209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.6
> Environment: intellij idea
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {noformat}
> Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
> 'canonicalization' in source unit
> '/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
> JVM class can't be loaded for example.gorm.service.PersonService
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
> at
> io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
> ...
> {noformat}
> {code:java|title=InjectVisitor#resolveParameterType}
> ClassNode parameterType = parameter.type
> if (parameterType.isResolved()) {
> parameterType.typeClass // here
> } else {
> parameterType.name
> }
> {code}
> Code: [https://github.com/pditommaso/mn-gorm-example]
> Steps to reproduce:
> 1. make sure the build is not delegated to Gradle in Preferences | Build,
> Execution, Deployment | Build Tools | Gradle
> 2. rebuild project
> 3. make changes in Person.groovy and Bootstrap.groovy (to mark them as
> subject for recompilation)
> 4. build project
> What happens with {{-Dgroovyc.asm.resolving.only=false}}:
> 1. Bootstrap.groovy and Person.groovy are added to
> {{CompilationUnit#queuedSources}}
> 2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
> 3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
> skipping {{findDecompiled}} call inside
> {{ClassNodeResolver#tryAsLoaderClassOrScript}}
> 4. the PersonService class fails to load because of missing Person class
> 5. {{tryAsScript}} kicks in and adds PersonService to
> {{CompilationUnit#queuedSources}}
> 6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
> PersonService
> What happens without {{-Dgroovyc.asm.resolving.only=false}}:
> 1. same
> 2. same
> 3. {{asmResolving}} is not set by IntellliJ
> 4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
> 5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
> PersonService, and this results in an exception because the class cannot be
> loaded actually.
> I've tried to fix it in the compiler but I'm not sure what's the proper fix
> would be.
> Please let me know if I can do something within IntelliJ.
> The issue in JB YouTrack for the reference:
> [https://youtrack.jetbrains.com/issue/IDEA-218698]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the antlr2 parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
P.S. antlr2 parser can prompt missing right parethesis smartly without any
error alternative
was:
Parrot parser parses large source code is much slower than the old parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the antlr2 parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source code in parallel.
> Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
> to enable/disable the improvement. For Groovy 3, the improvement is disabled
> by default, but for Groovy 4+, the improvement will be enabled.
> [1]
> https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
> P.S. antlr2 parser can prompt missing right parethesis smartly without any
> error alternative
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the old parser
because of the error alternative for better prompt[1]. In order to reduce the
whole parsing time, we could parse all the source code in parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement. For Groovy 3, the improvement is disabled by
default, but for Groovy 4+, the improvement will be enabled.
[1]
https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
was:
Parrot parser parses large source code is much slower than the old parser, in
order to reduce the whole parsing time, we could parse all the source code in
parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement.
For Groovy 3, the improvement is disabled by default, but for Groovy 4+, the
improvement will be enabled.
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the old parser
> because of the error alternative for better prompt[1]. In order to reduce the
> whole parsing time, we could parse all the source code in parallel.
> Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
> to enable/disable the improvement. For Groovy 3, the improvement is disabled
> by default, but for Groovy 4+, the improvement will be enabled.
> [1]
> https://github.com/apache/groovy/blob/GROOVY_3_0_4/src/antlr/GroovyParser.g4#L1259-L1261
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Description:
Parrot parser parses large source code is much slower than the old parser, in
order to reduce the whole parsing time, we could parse all the source code in
parallel.
Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
to enable/disable the improvement.
For Groovy 3, the improvement is disabled by default, but for Groovy 4+, the
improvement will be enabled.
was:
Parrot parser parses large source code is much slower than the old parser, in
order to reduce the whole parsing time, we could parse all the source code in
parallel.
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the old parser, in
> order to reduce the whole parsing time, we could parse all the source code in
> parallel.
> Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
> to enable/disable the improvement.
> For Groovy 3, the improvement is disabled by default, but for Groovy 4+, the
> improvement will be enabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9589) Parse source codes in parallel
[
https://issues.apache.org/jira/browse/GROOVY-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9589:
---
Fix Version/s: 3.0.5
> Parse source codes in parallel
> --
>
> Key: GROOVY-9589
> URL: https://issues.apache.org/jira/browse/GROOVY-9589
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Parrot parser parses large source code is much slower than the old parser, in
> order to reduce the whole parsing time, we could parse all the source code in
> parallel.
> Use compiler option {{parallelParse}} or JVM option {{groovy.parallel.parse}}
> to enable/disable the improvement.
> For Groovy 3, the improvement is disabled by default, but for Groovy 4+, the
> improvement will be enabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134731#comment-17134731
]
paolo di tommaso commented on GROOVY-9209:
--
This bug is still a source of lot of pains. Any progress would be appreciated.
> Compiler throws an exception in ClassNode#getTypeClass after checking
> ClassNode#isResolved
> --
>
> Key: GROOVY-9209
> URL: https://issues.apache.org/jira/browse/GROOVY-9209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.6
> Environment: intellij idea
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {noformat}
> Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
> 'canonicalization' in source unit
> '/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
> JVM class can't be loaded for example.gorm.service.PersonService
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
> at
> io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
> ...
> {noformat}
> {code:java|title=InjectVisitor#resolveParameterType}
> ClassNode parameterType = parameter.type
> if (parameterType.isResolved()) {
> parameterType.typeClass // here
> } else {
> parameterType.name
> }
> {code}
> Code: [https://github.com/pditommaso/mn-gorm-example]
> Steps to reproduce:
> 1. make sure the build is not delegated to Gradle in Preferences | Build,
> Execution, Deployment | Build Tools | Gradle
> 2. rebuild project
> 3. make changes in Person.groovy and Bootstrap.groovy (to mark them as
> subject for recompilation)
> 4. build project
> What happens with {{-Dgroovyc.asm.resolving.only=false}}:
> 1. Bootstrap.groovy and Person.groovy are added to
> {{CompilationUnit#queuedSources}}
> 2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
> 3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
> skipping {{findDecompiled}} call inside
> {{ClassNodeResolver#tryAsLoaderClassOrScript}}
> 4. the PersonService class fails to load because of missing Person class
> 5. {{tryAsScript}} kicks in and adds PersonService to
> {{CompilationUnit#queuedSources}}
> 6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
> PersonService
> What happens without {{-Dgroovyc.asm.resolving.only=false}}:
> 1. same
> 2. same
> 3. {{asmResolving}} is not set by IntellliJ
> 4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
> 5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
> PersonService, and this results in an exception because the class cannot be
> loaded actually.
> I've tried to fix it in the compiler but I'm not sure what's the proper fix
> would be.
> Please let me know if I can do something within IntelliJ.
> The issue in JB YouTrack for the reference:
> [https://youtrack.jetbrains.com/issue/IDEA-218698]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GROOVY-9586) CLONE - SC: calling trait method inside closure has incorrect receivers data
[
https://issues.apache.org/jira/browse/GROOVY-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-9586:
--
Fix Version/s: 3.0.5
> CLONE - SC: calling trait method inside closure has incorrect receivers data
>
>
> Key: GROOVY-9586
> URL: https://issues.apache.org/jira/browse/GROOVY-9586
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Reporter: Eric Milles
>Assignee: Eric Milles
>Priority: Major
> Fix For: 4.0.0-alpha-1, 3.0.5
>
>
> Consider the following
> {code:groovy}
> class C {
> def m(@DelegatesTo(strategy=Closure.OWNER_ONLY, type='Void') Closure
> block) {
> block.setResolveStrategy(Closure.OWNER_ONLY)
> block.setDelegate(null)
> return block.call()
> }
> def x() { 'C' }
> }
> trait T {
> def test() {
> new C().m { -> x() } // "x" must come from owner
> }
> def x() { 'T' }
> }
> class U implements T {
> }
> assert new U().test() == 'T'
> {code}
> Under static compilation, the implicit receiver metadata that is collected by
> StaticTypeCheckingVisitor is incorrect because the receiver T is only added
> for T$Trait$Helper under the delegate path. When using OWNER_ONLY, the trait
> is not checked and no direct method call target is set for "x()". So it
> falls back to dynamic behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [groovy] danielsun1106 opened a new pull request #1275: GROOVY-9589: Parse source codes in parallel
danielsun1106 opened a new pull request #1275: URL: https://github.com/apache/groovy/pull/1275 See https://issues.apache.org/jira/browse/GROOVY-9589 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GROOVY-9589) Parse source codes in parallel
Daniel Sun created GROOVY-9589: -- Summary: Parse source codes in parallel Key: GROOVY-9589 URL: https://issues.apache.org/jira/browse/GROOVY-9589 Project: Groovy Issue Type: Improvement Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 4.0.0-alpha-1 Parrot parser parses large source code is much slower than the old parser, in order to reduce the whole parsing time, we could parse all the source code in parallel. -- This message was sent by Atlassian Jira (v8.3.4#803005)
