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