[
https://issues.apache.org/jira/browse/GROOVY-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137326#comment-18137326
]
ASF GitHub Bot commented on GROOVY-12651:
-----------------------------------------
codeconsole opened a new pull request, #3172:
URL: https://github.com/apache/groovy/pull/3172
With closure packing (`@PackedClosures` or
`-Dgroovy.target.closure.pack=true`), the compile-time escape gate in
`ClosureWriter.collectEscapingClosures` treated only `=` on a non-local target
and `<<` as escapes. A literal stored or composed into a field, property or
index by a compound assignment was packed:
```groovy
@groovy.transform.PackedClosures
class C {
void install(Holder h) { h.handler ?= { x -> x * 2 } }
}
class Holder { Closure handler }
def h = new Holder()
new C().install(h)
h.handler.delegate = 'some delegate' // UnsupportedOperationException:
Cannot set a delegate on a @PackedClosures closure
```
`?=` and `??=` store the literal. `<<=` and `>>=` on a Closure slot store a
`ComposedClosure`, which keeps a clone of the literal (still a packed adapter)
and passes `setDelegate` on to it. `<<=` on a collection appends the literal,
and `+=` stores a new collection that contains it. The walk now treats `?=`,
`??=`, `>>=` and `+=` like `=` when the target is not a local, and `<<=` like
`<<`. The other compound operators do not leave the literal in the stored value
for the standard types, so they still pack, as do stores into a local.
Under `@CompileStatic`, `<<=`, `>>=` and `+=` are rewritten into method
calls before class generation, so they are declined only together with #3171
(GROOVY-12650), which runs the escape walk before that rewrite. `?=` and `??=`
keep their shape and are fixed here in every mode.
## Tests
`PackedClosuresTransformTest.compoundAssignmentEscapesAreDeclined` (dynamic
and `@TypeChecked`),
`PackedClosuresTransformTest.compileStaticCompoundStoresAreDeclined` and two
new rows in `PackedClosureBoundariesTest.boundaries` fail without the change.
The packing test classes, `org.codehaus.groovy.classgen.asm.sc.*` and
`groovy.transform.stc.*` (including `ClosuresSTCTest`) pass. The Checkstyle and
CodeNarc gates pass.
> Closure packing packs a closure literal stored or composed into a field,
> property or index by ?=, ??=, <<=, >>= or +=
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12651
> URL: https://issues.apache.org/jira/browse/GROOVY-12651
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 7.0.0-alpha-1
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> @groovy.transform.PackedClosures
> class C {
> void install(Holder h) { h.handler ?= { x -> x * 2 } }
> }
> class Holder { Closure handler }
> def h = new Holder()
> new C().install(h)
> h.handler.delegate = 'some delegate'
> println h.handler(21)
> {code}
> *Actual:* the literal is packed ({{PackedClosure$Fixed1}}), and setting the
> delegate throws {{UnsupportedOperationException: Cannot set a delegate on a
> @PackedClosures closure (hoisted method '$packed$closure$0') ...}}
> *Expected:* the closure escapes its method, so the escape gate declines it
> and keeps its closure class. The script then prints 42, as it does without
> packing.
> The same happens for {{??=}}, for {{<<=}} and {{>>=}} on a Closure slot (the
> stored ComposedClosure keeps a packed clone of the literal and passes
> setDelegate on to it), and for {{<<=}} and {{+=}} on a collection slot. It
> happens in dynamic code, under {{@TypeChecked}} and under {{@CompileStatic}},
> and with {{-Dgroovy.target.closure.pack=true}}.
> {{ClosureWriter.collectEscapingClosures}} counted only {{=}} on a non-local
> target and {{<<}} as escapes.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
