[jira] [Updated] (GROOVY-9460) Groovy 3 Compilation Failure with method with argument Class called with Class
[ https://issues.apache.org/jira/browse/GROOVY-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Puneet Behl updated GROOVY-9460: Description: While upgrading GORM to Groovy 3 we are seeing compilation error as: {code:java} > Task :grails-datastore-gorm:compileGroovy startup failed: /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 593: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 593, column 13. DynamicFinder.populateArgumentsForCriteria(persistentClass, q, params) ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 758: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 758, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 815: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 815, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ 3 errors > Task :grails-datastore-gorm:compileGroovy FAILED {code} Please check out and execute "\{{./gradlew cTG}}" in the following: [https://github.com/grails/grails-data-mapping/tree/groovyStaticTypeCheckingError] was: While upgrading GORM to Groovy 3 we are seeing compilation error as: {code} > Task :grails-datastore-gorm:compileGroovy startup failed: /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 593: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 593, column 13. DynamicFinder.populateArgumentsForCriteria(persistentClass, q, params) ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 758: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 758, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 815: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 815, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ 3 errors > Task :grails-datastore-gorm:compileGroovy FAILED {code} Please check out and run the following: https://github.com/grails/grails-data-mapping/tree/groovyStaticTypeCheckingError > Groovy 3 Compilation Failure with method with argument Class called with > Class > > > Key: GROOVY-9460 > URL: https://issues.apache.org/jira/browse/GROOVY-9460 > Project: Groovy > Issue Type: Bug > Components: Compiler >Affects Versions: 3.0.2 >Reporter: Puneet Behl >Priority: Major > > While upgrading GORM to Groovy 3 we are seeing compilation error as: > {code:java} > > Task :grails-datastore-gorm:compileGroovy > startup failed: > /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: > 593: [Static type checking] - Cannot call > org.grails.datastore.gorm.
[jira] [Created] (GROOVY-9460) Groovy 3 Compilation Failure with method with argument Class called with Class
Puneet Behl created GROOVY-9460: --- Summary: Groovy 3 Compilation Failure with method with argument Class called with Class Key: GROOVY-9460 URL: https://issues.apache.org/jira/browse/GROOVY-9460 Project: Groovy Issue Type: Bug Components: Compiler Affects Versions: 3.0.2 Reporter: Puneet Behl While upgrading GORM to Groovy 3 we are seeing compilation error as: {code} > Task :grails-datastore-gorm:compileGroovy startup failed: /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 593: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 593, column 13. DynamicFinder.populateArgumentsForCriteria(persistentClass, q, params) ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 758: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 758, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ /Users/pbehl/Projects/grails-data-mapping/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/GormStaticApi.groovy: 815: [Static type checking] - Cannot call org.grails.datastore.gorm.finders.DynamicFinder#populateArgumentsForCriteria(java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map ) with arguments [java.lang.Class , org.grails.datastore.mapping.query.Query, java.util.Map] @ line 815, column 13. DynamicFinder.populateArgumentsForCriteria persistentClass, q, args ^ 3 errors > Task :grails-datastore-gorm:compileGroovy FAILED {code} Please check out and run the following: https://github.com/grails/grails-data-mapping/tree/groovyStaticTypeCheckingError -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9204) Compiler loses type info of superclass field
[ https://issues.apache.org/jira/browse/GROOVY-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057163#comment-17057163 ] Daniil Ovchinnikov commented on GROOVY-9204: [~katoquro] no. Next time please create another issue, since it will be much more easier to mark it as a duplicate if it turns out to be such. > Compiler loses type info of superclass field > > > Key: GROOVY-9204 > URL: https://issues.apache.org/jira/browse/GROOVY-9204 > Project: Groovy > Issue Type: Bug > Components: Static compilation, Static Type Checker >Affects Versions: 2.5.7 >Reporter: Daniil Ovchinnikov >Assignee: Daniel Sun >Priority: Blocker > Fix For: 3.0.0, 2.5.10 > > Time Spent: 1.5h > Remaining Estimate: 0h > > {code:java|title=foo/bar/classes.java} > package foo.bar; > class F { > void hi() {} > } > abstract class Base { > protected T theField; > } > abstract class Middle extends Base {} > abstract class Concrete extends Middle {} > {code} > {code:java|title=foo/bar/GroovyUsage.groovy} > package foo.bar > @groovy.transform.CompileStatic > class GroovyUsage extends Concrete { > def usage() { > theField.hi() // Error:(7, 9) Groovyc: [Static type checking] - > Cannot find matching method java.lang.Object#hi(). Please check if the > declared type is correct and if the method exists. > } > } > {code} > Note this was working with 2.4.17. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9459) Line number information for automatically inserted return statements quirky
[ https://issues.apache.org/jira/browse/GROOVY-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057120#comment-17057120 ] Paul King commented on GROOVY-9459: --- Hi [~emilles], we'd need to check whether the missing info for the ExpressionStatement is from the Spock or Groovy side. If on the Groovy side, it is easy for us to fix on our end. If it's on the Spock side, we can push back on them to fix it but chances are our change in behavior might cause headaches for other downstream projects and we'd need to assist them too at some point. The appeal of Björn's suggestion (grabbing from ExpressionStatement as per current 3/master code but if the ExpressionStatement has no line number info, grab instead from the inner expression to preserve 2.5 behavior in that case) is that the likelihood of downstream headaches is small. Does the suggestion seem reasonable to you? > Line number information for automatically inserted return statements quirky > --- > > Key: GROOVY-9459 > URL: https://issues.apache.org/jira/browse/GROOVY-9459 > Project: Groovy > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Björn Kautler >Priority: Major > > While trying to work-around GROOVY-9440, I found another quirk regarding line > numbers. > I'm sorry if this is intended and not a bug, but it looks strange to me. > Here what I found out so far: > > The Spock AST transformation previously had (semantically equivalent) {{new > ReturnStatement(new ExpressionStatement(theVariableExpression)))}} where the > two statements have no line information, the expression does have it. > This caused the line information to be missing from the > {{MissingPropertyException}}. > If I look at the AST Browser at end of semantic analysis, this results in > {{ReturnStatement -> Variable}} where the return statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > > I thought as work-around I remove the explicit return statement and let > Groovy handle it, as it knows better what to do, so currently I have {{new > ExpressionStatement(theVariableExpression))}} where the statement still has > no line information, but the expression does have it. > This now causes the line information to be missing from the > {{MissingPropertyException}} still, if Groovy 3.0.0 is used. > If I look at the AST Browser at end of semantic analysis, this results in > {{ExpressionStatement -> Variable}} where the statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > If I now look at the end of class generation, this results in > {{ReturnStatement -> Variable}} in both 2.5.8 and 3.0.0, but only 2.5.8 has > line information for the return statement, in 3.0.0 it is {{-1}}. > > I now tried {{ExpressionStatement exprStat = new > ExpressionStatement(theVariableExpression)); exprStat.setLineNumber(666);}} > and now it gets even fancier. > In 2.5.8 the return statement takes the line information from the variable > expression, ignoring the expression statement, > in 3.0.0 the return statement takes the line information from the expression > statement. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9459) Line number information for automatically inserted return statements quirky
[ https://issues.apache.org/jira/browse/GROOVY-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057065#comment-17057065 ] Eric Milles commented on GROOVY-9459: - The idea in ReturnAdder is to pass on metadata from the statement that is being replaced. When the ExpressionStatement is inserted, could it have source position set at that time? If ReturnAdder is changed, what about the case where the ExpressionStatement has source position but the expression within it (for whatever reason) does not? > Line number information for automatically inserted return statements quirky > --- > > Key: GROOVY-9459 > URL: https://issues.apache.org/jira/browse/GROOVY-9459 > Project: Groovy > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Björn Kautler >Priority: Major > > While trying to work-around GROOVY-9440, I found another quirk regarding line > numbers. > I'm sorry if this is intended and not a bug, but it looks strange to me. > Here what I found out so far: > > The Spock AST transformation previously had (semantically equivalent) {{new > ReturnStatement(new ExpressionStatement(theVariableExpression)))}} where the > two statements have no line information, the expression does have it. > This caused the line information to be missing from the > {{MissingPropertyException}}. > If I look at the AST Browser at end of semantic analysis, this results in > {{ReturnStatement -> Variable}} where the return statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > > I thought as work-around I remove the explicit return statement and let > Groovy handle it, as it knows better what to do, so currently I have {{new > ExpressionStatement(theVariableExpression))}} where the statement still has > no line information, but the expression does have it. > This now causes the line information to be missing from the > {{MissingPropertyException}} still, if Groovy 3.0.0 is used. > If I look at the AST Browser at end of semantic analysis, this results in > {{ExpressionStatement -> Variable}} where the statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > If I now look at the end of class generation, this results in > {{ReturnStatement -> Variable}} in both 2.5.8 and 3.0.0, but only 2.5.8 has > line information for the return statement, in 3.0.0 it is {{-1}}. > > I now tried {{ExpressionStatement exprStat = new > ExpressionStatement(theVariableExpression)); exprStat.setLineNumber(666);}} > and now it gets even fancier. > In 2.5.8 the return statement takes the line information from the variable > expression, ignoring the expression statement, > in 3.0.0 the return statement takes the line information from the expression > statement. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9204) Compiler loses type info of superclass field
[ https://issues.apache.org/jira/browse/GROOVY-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057049#comment-17057049 ] Andrew Malyhin commented on GROOVY-9204: Hello! I think I've faced with the similar issue on 2.5.10 when I used apache sshd I have this compilation error {code:java} shell/Example.groovy: 26: [Static type checking] - Cannot find matching method org.apache.sshd.client.SshClient#connect(org.apache.sshd.client.config.hosts.HostConfigEntry). Please check if the declared type is correct and if the method exists. @ line 26, column 33. ClientSession session = ssh.connect(hostConfig).verify(0L).getSession() {code} in the next code {code:java} package shell import groovy.transform.CompileStatic import org.apache.sshd.client.SshClient import org.apache.sshd.client.config.hosts.HostConfigEntry import org.apache.sshd.client.session.ClientSession import java.nio.file.Path @CompileStatic abstract class Example { final Path privateKey final String username final SshClient ssh Example(SshClient ssh, Path privateKey, String username) { this.ssh = ssh this.privateKey = privateKey this.username = username } protected ClientSession createSession(String host) { HostConfigEntry hostConfig = new HostConfigEntry("", host, 22, username) hostConfig.addIdentity(privateKey) ClientSession session = ssh.connect(hostConfig).verify(0L).getSession() session.auth().verify(0L) return session } } {code} Is this the same issue? > Compiler loses type info of superclass field > > > Key: GROOVY-9204 > URL: https://issues.apache.org/jira/browse/GROOVY-9204 > Project: Groovy > Issue Type: Bug > Components: Static compilation, Static Type Checker >Affects Versions: 2.5.7 >Reporter: Daniil Ovchinnikov >Assignee: Daniel Sun >Priority: Blocker > Fix For: 3.0.0, 2.5.10 > > Time Spent: 1.5h > Remaining Estimate: 0h > > {code:java|title=foo/bar/classes.java} > package foo.bar; > class F { > void hi() {} > } > abstract class Base { > protected T theField; > } > abstract class Middle extends Base {} > abstract class Concrete extends Middle {} > {code} > {code:java|title=foo/bar/GroovyUsage.groovy} > package foo.bar > @groovy.transform.CompileStatic > class GroovyUsage extends Concrete { > def usage() { > theField.hi() // Error:(7, 9) Groovyc: [Static type checking] - > Cannot find matching method java.lang.Object#hi(). Please check if the > declared type is correct and if the method exists. > } > } > {code} > Note this was working with 2.4.17. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9459) Line number information for automatically inserted return statements quirky
[ https://issues.apache.org/jira/browse/GROOVY-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056915#comment-17056915 ] Paul King commented on GROOVY-9459: --- [~emilles] In this change here: https://github.com/apache/groovy/commit/a54966c7bc Line 128 <=> 135 Is that a useful change from the Eclipse side of things? Or an unintended change? If useful, would it make sense to revert back to setting from the expression if the expression statement has no positioning info? > Line number information for automatically inserted return statements quirky > --- > > Key: GROOVY-9459 > URL: https://issues.apache.org/jira/browse/GROOVY-9459 > Project: Groovy > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Björn Kautler >Priority: Major > > While trying to work-around GROOVY-9440, I found another quirk regarding line > numbers. > I'm sorry if this is intended and not a bug, but it looks strange to me. > Here what I found out so far: > > The Spock AST transformation previously had (semantically equivalent) {{new > ReturnStatement(new ExpressionStatement(theVariableExpression)))}} where the > two statements have no line information, the expression does have it. > This caused the line information to be missing from the > {{MissingPropertyException}}. > If I look at the AST Browser at end of semantic analysis, this results in > {{ReturnStatement -> Variable}} where the return statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > > I thought as work-around I remove the explicit return statement and let > Groovy handle it, as it knows better what to do, so currently I have {{new > ExpressionStatement(theVariableExpression))}} where the statement still has > no line information, but the expression does have it. > This now causes the line information to be missing from the > {{MissingPropertyException}} still, if Groovy 3.0.0 is used. > If I look at the AST Browser at end of semantic analysis, this results in > {{ExpressionStatement -> Variable}} where the statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > If I now look at the end of class generation, this results in > {{ReturnStatement -> Variable}} in both 2.5.8 and 3.0.0, but only 2.5.8 has > line information for the return statement, in 3.0.0 it is {{-1}}. > > I now tried {{ExpressionStatement exprStat = new > ExpressionStatement(theVariableExpression)); exprStat.setLineNumber(666);}} > and now it gets even fancier. > In 2.5.8 the return statement takes the line information from the variable > expression, ignoring the expression statement, > in 3.0.0 the return statement takes the line information from the expression > statement. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-9459) Line number information for automatically inserted return statements quirky
[ https://issues.apache.org/jira/browse/GROOVY-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056914#comment-17056914 ] Björn Kautler commented on GROOVY-9459: --- After talking a bit with Paul about it, it seems to make sense to take the information from the {{ExpressionStatement}} which was the change in 3.0.0. But as the {{ExpressionStatement}} gets replaced by the {{ReturnStatement}}, would it maybe make sense to have some logic like "take the info from {{ExpressionStatement}} if present and if not, take it from the wrapped {{Expression}} instead"? > Line number information for automatically inserted return statements quirky > --- > > Key: GROOVY-9459 > URL: https://issues.apache.org/jira/browse/GROOVY-9459 > Project: Groovy > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Björn Kautler >Priority: Major > > While trying to work-around GROOVY-9440, I found another quirk regarding line > numbers. > I'm sorry if this is intended and not a bug, but it looks strange to me. > Here what I found out so far: > > The Spock AST transformation previously had (semantically equivalent) {{new > ReturnStatement(new ExpressionStatement(theVariableExpression)))}} where the > two statements have no line information, the expression does have it. > This caused the line information to be missing from the > {{MissingPropertyException}}. > If I look at the AST Browser at end of semantic analysis, this results in > {{ReturnStatement -> Variable}} where the return statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > > I thought as work-around I remove the explicit return statement and let > Groovy handle it, as it knows better what to do, so currently I have {{new > ExpressionStatement(theVariableExpression))}} where the statement still has > no line information, but the expression does have it. > This now causes the line information to be missing from the > {{MissingPropertyException}} still, if Groovy 3.0.0 is used. > If I look at the AST Browser at end of semantic analysis, this results in > {{ExpressionStatement -> Variable}} where the statement has no line > information, the variable does have it, in both 2.5.8 and 3.0.0. > If I now look at the end of class generation, this results in > {{ReturnStatement -> Variable}} in both 2.5.8 and 3.0.0, but only 2.5.8 has > line information for the return statement, in 3.0.0 it is {{-1}}. > > I now tried {{ExpressionStatement exprStat = new > ExpressionStatement(theVariableExpression)); exprStat.setLineNumber(666);}} > and now it gets even fancier. > In 2.5.8 the return statement takes the line information from the variable > expression, ignoring the expression statement, > in 3.0.0 the return statement takes the line information from the expression > statement. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GROOVY-9459) Line number information for automatically inserted return statements quirky
Björn Kautler created GROOVY-9459: - Summary: Line number information for automatically inserted return statements quirky Key: GROOVY-9459 URL: https://issues.apache.org/jira/browse/GROOVY-9459 Project: Groovy Issue Type: Bug Affects Versions: 3.0.0 Reporter: Björn Kautler While trying to work-around GROOVY-9440, I found another quirk regarding line numbers. I'm sorry if this is intended and not a bug, but it looks strange to me. Here what I found out so far: The Spock AST transformation previously had (semantically equivalent) {{new ReturnStatement(new ExpressionStatement(theVariableExpression)))}} where the two statements have no line information, the expression does have it. This caused the line information to be missing from the {{MissingPropertyException}}. If I look at the AST Browser at end of semantic analysis, this results in {{ReturnStatement -> Variable}} where the return statement has no line information, the variable does have it, in both 2.5.8 and 3.0.0. I thought as work-around I remove the explicit return statement and let Groovy handle it, as it knows better what to do, so currently I have {{new ExpressionStatement(theVariableExpression))}} where the statement still has no line information, but the expression does have it. This now causes the line information to be missing from the {{MissingPropertyException}} still, if Groovy 3.0.0 is used. If I look at the AST Browser at end of semantic analysis, this results in {{ExpressionStatement -> Variable}} where the statement has no line information, the variable does have it, in both 2.5.8 and 3.0.0. If I now look at the end of class generation, this results in {{ReturnStatement -> Variable}} in both 2.5.8 and 3.0.0, but only 2.5.8 has line information for the return statement, in 3.0.0 it is {{-1}}. I now tried {{ExpressionStatement exprStat = new ExpressionStatement(theVariableExpression)); exprStat.setLineNumber(666);}} and now it gets even fancier. In 2.5.8 the return statement takes the line information from the variable expression, ignoring the expression statement, in 3.0.0 the return statement takes the line information from the expression statement. -- This message was sent by Atlassian Jira (v8.3.4#803005)