[
https://issues.apache.org/jira/browse/GROOVY-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Murphy Heiberg updated GROOVY-12650:
------------------------------------------
Affects Version/s: (was: 7.0.0-alpha-1)
> Closure packing packs closures that escape via << or a setter store under
> @CompileStatic
> ----------------------------------------------------------------------------------------
>
> Key: GROOVY-12650
> URL: https://issues.apache.org/jira/browse/GROOVY-12650
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> // -Dgroovy.target.closure.pack=true, or @PackedClosures on the class/method
> class H { Closure value }
> @groovy.transform.CompileStatic def m() {
> List<Closure> l = []
> l << { 1 }
> def h = new H()
> h.value = { 2 }
> [l[0].getClass().name, h.value.getClass().name]
> }
> m()
> {code}
> *Actual:* {{[org.codehaus.groovy.runtime.PackedClosure$FixedIt,
> org.codehaus.groovy.runtime.PackedClosure$FixedIt]}}. Both escaping closures
> are packed.
> *Expected:* {{[Script1$_m_closure1, Script1$_m_closure2]}}. Both closures
> escape the method and should be declined from packing, as they are in dynamic
> Groovy and under {{@TypeChecked}}.
> The packing escape check ({{ClosureWriter.collectEscapingClosures}}) walks
> the method body at class generation. Under static compilation,
> {{BinaryExpressionTransformer}} has already rewritten the {{<<}} into a
> {{leftShift}} call and the setter-backed property store into a setter call,
> so the walk no longer recognises them as escapes. Other escape shapes
> (subscript, map and field stores, named constructor arguments, stores to a
> property of the same class) are already declined under {{@CompileStatic}}.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
