Scott Murphy Heiberg created GROOVY-12650:
---------------------------------------------
Summary: 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: 7.0.0-alpha-1
Reporter: Scott Murphy Heiberg
{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)
