[
https://issues.apache.org/jira/browse/GROOVY-12663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137398#comment-18137398
]
ASF GitHub Bot commented on GROOVY-12663:
-----------------------------------------
codeconsole opened a new pull request, #3184:
URL: https://github.com/apache/groovy/pull/3184
In dynamic code, `@PackedClosures` hoists a closure into a method of the
owner class on the annotation's word. Calls that dynamic Groovy resolves
against a closure object then reach the owner instead:
```groovy
class C {
String toString() { 'C' }
@groovy.transform.PackedClosures Object m() { Closure outer = { -> { ->
toString() }() }; [outer(), outer.toString()] }
@groovy.transform.PackedClosures Object mem() { def c = { -> memoize()
}; c() }
}
new C().m() // [C, C.$packed$closure$0@…]: the owner's toString, not the
outer closure's
new C().mem() // MissingMethodException: No signature of method: memoize
for class: C
```
The same happens for other methods `Closure` declares (`curry`, `dehydrate`,
`rehydrate`, `asWritable`, `trampoline`, `rightShift`) and recursion through
`call`/`doCall` (`clone()` calls `Object.clone()` on the owner); for bare
`maximumNumberOfParameters` and `parameterTypes`, which throw
MissingPropertyException; and for `hashCode()`, `equals()`, `getClass()` and
GDK methods such as `with` or `is` in a nested closure, which
`ClosureMetaClass` answers on the enclosing closure while in a hoisted body the
nested closure's owner is the owner instance. Seen in 6.0.0 too.
The dynamic path of the packing decision (`ClosureWriter.isPackTriggered`)
now declines such a closure. The check is by name, since there are no types: in
the closure's own body, an implicit-this call to a public `Closure` method that
`Object` does not declare, or to `doCall`, or a read of a `Closure` property;
in a closure nested directly in the body, an implicit-this call to an `Object`
method or to a GDK method a closure has (`print`, `println` and `printf` are
excluded, because their `Closure` versions forward to the owner). `Object` and
GDK methods called in the closure's own body go to the owner first and still
pack. `ClosureWriter.triggerDeclineReason` gives the reason to WARN and STRICT.
The `@CompileStatic` writer is unchanged; #3181 (GROOVY-12660) covers it.
## Tests
`PackedClosuresTransformTest.dynamicClosuresCallingClosureMethodsDecline`,
`dynamicClosuresCallingObjectMethodsInANestedClosureDecline` and
`strictModeReportsDynamicClosureReceiverDecline` fail without the change; the
second also checks that owner-resolved shapes still pack. The packing test
classes, `groovy.lang.*Closure*`, `groovy.ClosureTest`,
`groovy.transform.stc.*` and `org.codehaus.groovy.classgen.asm.sc.*` pass. The
Checkstyle and CodeNarc gates pass.
> @PackedClosures packs dynamic closures whose calls resolve against a closure
> object, calling the owner instead
> --------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12663
> URL: https://issues.apache.org/jira/browse/GROOVY-12663
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 7.0.0-alpha-1, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> class C {
> String toString() { 'C' }
> @groovy.transform.PackedClosures Object m() { Closure outer = { -> { ->
> toString() }() }; [outer(), outer.toString()] }
> @groovy.transform.PackedClosures Object mem() { def c = { -> memoize() };
> c() }
> }
> println new C().m()
> new C().mem()
> {code}
> *Actual:* {{m()}} returns {{[C, C.$packed$closure$0@...]}} (the owner's
> toString, not the outer closure's), and {{mem()}} throws
> {{MissingMethodException: No signature of method: memoize for class: C}}. The
> same happens for:
> * other methods Closure declares: curry, dehydrate, rehydrate, asWritable,
> trampoline, rightShift, and recursion through call or doCall; clone() throws
> CloneNotSupportedException;
> * the properties maximumNumberOfParameters and parameterTypes, which throw
> MissingPropertyException;
> * hashCode, equals, getClass and GDK methods such as with or is in a nested
> closure.
> *Expected:* the same results as without the annotation. Methods that Closure
> declares resolve against the closure itself, and Object and GDK methods
> called in a nested closure resolve against the enclosing closure.
> Cause: in dynamic code the annotation is trusted, and the packing check only
> rejects the pseudo-property calls such as getDelegate(). The hoisted body is
> a method of the owner class, and a nested closure created in it gets the
> owner instance as its owner, so these calls reach the owner. The
> @CompileStatic counterpart is GROOVY-12660.
> Verified on 6.0.0 and master.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
