[
https://issues.apache.org/jira/browse/GROOVY-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135660#comment-18135660
]
ASF GitHub Bot commented on GROOVY-12622:
-----------------------------------------
codeconsole opened a new pull request, #3148:
URL: https://github.com/apache/groovy/pull/3148
Under `@CompileStatic`, `++` and `--` on a non-primitive property or
subscript element evaluated the operand twice:
```groovy
@groovy.transform.CompileStatic
class Box {
int gets = 0
BigDecimal d = 1
BigDecimal getD() { gets++; d }
void setD(BigDecimal v) { d = v }
}
@groovy.transform.CompileStatic
def m() { def b = new Box(); b.d++; [b.gets, b.@d] }
assert m() == [1, 2] // was [2, 2]
```
For a subscript such as `list[idx++]++` on a `List<Integer>`, the receiver
and index expressions ran again too, so the incremented value of the next
element was stored into the first one (`[2, [21, 20], 10]` instead of `[1, [11,
20], 10]`). Dynamic Groovy and `@TypeChecked` read the operand once. 4.0.33,
5.0.8 and 6.0.0 behave the same.
When STC has resolved `next()`/`previous()`,
`StaticTypesBinaryExpressionMultiTypeDispatcher.writePostOrPrefixMethod` popped
the value already loaded and called the method on the operand expression again.
It now stores that value in a temporary and makes the call on it, with the same
method target, as `emitCompoundAssignCall` in the same class does. Postfix
still yields the old value and prefix the new one. Primitive operands and the
dynamic and `@TypeChecked` code generation are unchanged.
This and #3145 (GROOVY-12619, receiver of a compound-assigned or incremented
property evaluated once) touch different files; together, `obj().d++` evaluates
both the receiver and the getter once.
## Tests
The new tests in `STCAssignmentTest` run under `@TypeChecked` and, through
`AssignmentsStaticCompileTest`, under `@CompileStatic`. Four of them fail under
`@CompileStatic` without the change:
`testPostfixAndPrefixOnPropertyCallGetterOnce`,
`testPostfixAndPrefixOnPropertyCallGetterOnce2`,
`testPostfixAndPrefixOnSubscriptCallGetAtOnce` and
`testPostfixAndPrefixOnSubscriptEvaluateIndexOnce`. Between them they cover
wrapper, BigDecimal, String, Character and custom `next()` properties, static
properties, closures, lambdas, safe navigation, a custom getAt/putAt, and lists
and arrays with a side-effecting index. `testPostfixAndPrefixOnLocalVariable`
guards locals. The `groovy.transform.stc`, `org.codehaus.groovy.classgen.asm`
(including `.sc`), `gls`, `groovy.bugs` and `groovy.operator` packages pass.
The Checkstyle and CodeNarc gates pass.
> SC evaluates the operand twice for ++ and -- on a non-primitive property or
> subscript
> -------------------------------------------------------------------------------------
>
> Key: GROOVY-12622
> URL: https://issues.apache.org/jira/browse/GROOVY-12622
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> @groovy.transform.CompileStatic
> class Box {
> int gets = 0
> BigDecimal d = 1
> BigDecimal getD() { gets++; d }
> void setD(BigDecimal v) { d = v }
> }
> @groovy.transform.CompileStatic
> def m() { def b = new Box(); b.d++; [b.gets, b.@d] }
> assert m() == [1, 2]
> @groovy.transform.CompileStatic
> def n() { int idx = 0; List<Integer> list = [10, 20]; def r = list[idx++]++;
> [idx, list, r] }
> assert n() == [1, [11, 20], 10]
> {code}
> Actual: m() returns [2, 2] (getD is called twice), and n() returns [2, [21,
> 20], 10]: the index expression runs twice and the incremented value of
> list[1] is stored into list[0].
> Expected: [1, 2] and [1, [11, 20], 10], as in dynamic Groovy and with
> @TypeChecked.
> When next() or previous() has a resolved target,
> StaticTypesBinaryExpressionMultiTypeDispatcher.writePostOrPrefixMethod
> discards the operand value already loaded and makes the call on the operand
> expression again. That evaluates the getter or getAt (and a subscript's
> receiver and index) a second time.
> Seen in 4.0.33, 5.0.8 and 6.0.0.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
