[ 
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)

Reply via email to