[
https://issues.apache.org/jira/browse/GROOVY-12650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140530#comment-18140530
]
ASF GitHub Bot commented on GROOVY-12650:
-----------------------------------------
codeconsole commented on PR #3171:
URL: https://github.com/apache/groovy/pull/3171#issuecomment-6717052502
@daniellansun I can't re-run jobs on apache/groovy, so I merged current
master (492ae79db4) to get a fresh run. The failed cell was the `lts (17,
windows-latest, 1)` timeout. No code changes; `PackedClosuresTransformTest`
passes locally on the merge.
> 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)