[
https://issues.apache.org/jira/browse/GROOVY-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135591#comment-18135591
]
ASF GitHub Bot commented on GROOVY-12603:
-----------------------------------------
codeconsole opened a new pull request, #3130:
URL: https://github.com/apache/groovy/pull/3130
A compound assignment, increment or decrement of a trait field inside a
closure or lambda lost the update or failed:
```groovy
trait T {
private int x = 1
def m() { [1].each { x++ }; [1].each { x += 2 }; x }
}
class C implements T {}
new C().m()
```
Dynamic Groovy returns 1. With `@CompileStatic` the `+=` throws
`GroovyCastException: Cannot cast object '3' with class 'java.lang.Integer' to
class 'T'`. For a static field, or in a lambda, `@CompileStatic` fails at
compile time instead. 4.0.33, 5.0.8 and 6.0.0 behave the same.
In a trait method body, `NAryOperationRewriter` rewrites `x op= y` into `x =
x op y` and rejects prefix and postfix operations on trait fields. It did not
visit closure bodies, because `ClassCodeExpressionTransformer.transform` leaves
a `ClosureExpression` untouched. `TraitReceiverTransformer` then turned the
field into a field-helper getter call, and the operator was applied to the call
result.
`NAryOperationRewriter` now visits closure and lambda bodies. Inside them it
rewrites a compound assignment only when the target is a trait field, so other
targets keep their compound semantics. It applies the existing prefix/postfix
rejection there too. `x += 2` now updates the field in all compile modes. `x++`
inside a closure gets the same compile error as in a method body, which is the
documented limitation ("Prefix and postfix operations" in the traits guide).
#3125 (GROOVY-12598) leaves trait properties referenced from a closure for
the closure to resolve, which would let `x++` on a property work there. If both
land, the closure-level prefix/postfix rejection can skip properties when not
in a lambda.
## Tests
`TraitASTTransformationTest.testCompoundAssignmentOfTraitFieldInClosure`
(dynamic, `@TypeChecked`, `@CompileStatic`) and
`TraitASTTransformationTest.testPrefixOrPostfixOfTraitFieldInClosure` fail
without the change. They cover private, public and static fields, instance and
static methods, closures and lambdas. `org.codehaus.groovy.transform.traitx.*`,
`TraitsSpecificationTest`, `groovy.transform.stc.*`,
`org.codehaus.groovy.classgen.asm.sc.*` and `groovy.ThisAndSuperTest` pass. The
Checkstyle and CodeNarc gates pass.
> Compound assignment, increment or decrement of a trait field inside a closure
> or lambda loses the update or fails
> -----------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12603
> URL: https://issues.apache.org/jira/browse/GROOVY-12603
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> trait T {
> private int x = 1
> def m() { [1].each { x++ }; [1].each { x += 2 }; x }
> }
> class C implements T {}
> new C().m()
> {code}
> Actual: m() returns 1 because both updates are lost. With @CompileStatic on
> the trait, the += throws GroovyCastException: Cannot cast object '3' with
> class 'java.lang.Integer' to class 'T'. For a static field, or inside a
> lambda, @CompileStatic fails at compile time instead ("Cannot access method:
> T__x$get() of class: java.lang.Object", or an ASM instruction selection
> error). The same applies to public and static fields, x--, ++x, and the other
> compound operators.
> Expected: x += 2 and the other compound operators update the field, as they
> do in a trait method body. x++, x--, ++x and --x are rejected at compile time
> with "Postfix/Prefix expressions on trait fields/properties are not supported
> in traits", as they are in a trait method body.
> Cause: the trait transformation rewrites x op= y into x = x op y and rejects
> prefix and postfix operations on trait fields, but that rewriter never
> visited closure or lambda bodies. The field reference inside the closure was
> turned into a field-helper getter call, and the operator was applied to the
> call result.
> Seen in 4.0.33, 5.0.8 and 6.0.0.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
