[
https://issues.apache.org/jira/browse/GROOVY-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135625#comment-18135625
]
ASF GitHub Bot commented on GROOVY-12613:
-----------------------------------------
codeconsole opened a new pull request, #3140:
URL: https://github.com/apache/groovy/pull/3140
In a trait method, every compound assignment `a op= b` was rewritten to `a =
a op b`, so its target was evaluated twice:
```groovy
trait T {
def m() { def l = [0, 0]; int i = 0; l[i++] += 1; [i, l] }
}
class C implements T {}
assert new C().m() == [1, [1, 0]] // was [2, [1, 0]]; a class method gives
[1, [1, 0]]
```
4.0.33, 5.0.8 and 6.0.0 behave the same. `NAryOperationRewriter` does this
rewrite so that a compound assignment to a trait field can become a
field-helper getter and setter call. It applied it to every target, so for a
local, a subscript or another object's property it changed the evaluation order
and count: `l[i++] += 1` incremented `i` twice and `map[key()] += 1` called
`key()` twice. The rewriter now leaves a compound assignment unchanged unless
its target is a trait field or a `this.`-qualified trait field
(`isInternalFieldAccess`, the same check the prefix and postfix rejection
uses). Compound assignment to private, public and static trait fields and to
trait properties is rewritten as before.
#3130 (GROOVY-12603) also changes
`NAryOperationRewriter.transformBinaryExpression`, to visit closures; whichever
lands second keeps this unconditional field check and drops the closure-only
one there.
## Tests
`TraitASTTransformationTest.testCompoundAssignmentEvaluatesTargetOnce` fails
without the change in dynamic, `@TypeChecked` and `@CompileStatic` modes.
`testCompoundAssignmentOfTraitFieldOrProperty` covers compound assignment to
trait fields and properties in the same three modes.
`org.codehaus.groovy.transform.traitx`, `groovy.transform.stc`,
`org.codehaus.groovy.classgen.asm.sc`, `gls.innerClass`, `PackedClosure*` and
`groovy.ThisAndSuperTest` pass. The Checkstyle and CodeNarc gates pass.
> Compound assignment in a trait method evaluates its target twice when the
> target is not a trait field
> -----------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12613
> URL: https://issues.apache.org/jira/browse/GROOVY-12613
> 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 {
> def m() { def l = [0, 0]; int i = 0; l[i++] += 1; [i, l] }
> }
> class C implements T {}
> assert new C().m() == [1, [1, 0]]
> {code}
> Actual: {{new C().m()}} returns {{[2, [1, 0]]}}. The index expression runs
> twice. The same method in a class returns {{[1, [1, 0]]}}. The receiver or
> subscript of any compound assignment in a trait method is evaluated twice,
> for example a map subscript key() is called twice. This happens with and
> without @CompileStatic / @TypeChecked.
> Expected: {{[1, [1, 0]]}}. A compound assignment evaluates its target once,
> as it does in a class.
> Cause: the trait transformation (NAryOperationRewriter) rewrites every
> compound assignment in trait code into a plain assignment (a = a op b). The
> rewrite is only needed when the target is a trait field, which becomes a
> field-helper getter/setter call.
> Seen in 4.0.33, 5.0.8 and 6.0.0.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
