[ 
https://issues.apache.org/jira/browse/GROOVY-12678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137474#comment-18137474
 ] 

ASF GitHub Bot commented on GROOVY-12678:
-----------------------------------------

codeconsole opened a new pull request, #3199:
URL: https://github.com/apache/groovy/pull/3199

   Under `@CompileStatic`, `owner` and `delegate` (and `getOwner()` and 
`getDelegate()`) inside a lambda nested in a closure or another lambda were 
typed as `Closure`:
   
   ```groovy
   @CompileStatic
   class C {
       String name = 'n'
       def q() {
           Supplier<Supplier<Object>> s = () -> { name; (Supplier<Object>) (() 
-> { name; owner.maximumNumberOfParameters }) }
           s.get().get() // GroovyCastException: Cannot cast object 'C@…' with 
class 'C' to class 'groovy.lang.Closure'
       }
       def t() {
           def c = { -> Supplier<String> s = () -> { name; owner.name }; 
s.get() }
           c() // No such property: name for class: groovy.lang.Closure
       }
   }
   ```
   
   Seen in 4.0.33, 5.0.8 and 6.0.0 too.
   
   A native lambda is constructed with the enclosing `this` as its owner 
(`ClosureWriter.loadThis` reads `getThisObject()` inside a generated function), 
so its owner is the enclosing instance at any depth. The type checker 
(`StaticTypeCheckingVisitor.hasClosureOwner`) now types `owner` and `delegate` 
in such a lambda as the enclosing class, as it already did for a top-level 
lambda. A lambda counts as native when it is statically compiled and its target 
type is a functional interface, the same rule 
`StaticTypesLambdaWriter.writeLambda` uses. Closures and lambdas compiled as 
closures (type-checked code, or no functional-interface target) still get 
`Closure`, since their owner is the enclosing closure or lambda.
   
   With #3193 (GROOVY-12672) also merged, a nested lambda that reads `owner` 
but no instance member works at run time too (without it, such a lambda gets a 
static `doCall`). The two merge cleanly, and cleanly with #3189 (GROOVY-12668).
   
   ## Tests
   
   `LambdaTest.testNestedLambdaOwnerDelegateThisObject` and 
`ClosuresStaticCompileTest.testNestedLambdaDelegateOwner` fail without the 
change. `LambdaTest.testClosureOwnerInNestedFunction` and 
`ClosuresSTCTest.testNestedLambdaDelegateOwner` check that closures, lambdas 
compiled as closures and type-checked lambdas keep the `Closure` owner. 
`groovy.transform.stc.*` and `org.codehaus.groovy.classgen.asm.sc.*` pass. The 
Checkstyle and CodeNarc gates pass.
   




> STC types owner and delegate as Closure inside a lambda nested in a closure 
> or lambda, so SC throws GroovyCastException
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12678
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12678
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.33, 5.0.8, 7.0.0-alpha-1, 6.0.0
>            Reporter: Scott Murphy Heiberg
>            Priority: Major
>
> {code:groovy}
> import java.util.function.Supplier
> @groovy.transform.CompileStatic
> class C {
>     String name = 'n'
>     def q() {
>         Supplier<Supplier<Object>> s = () -> { name; (Supplier<Object>) (() 
> -> { name; owner.maximumNumberOfParameters }) }
>         s.get().get()
>     }
>     def r() {
>         def c = { -> Supplier<Object> s = () -> { name; 
> owner.maximumNumberOfParameters }; s.get() }
>         c()
>     }
>     def t() {
>         def c = { -> Supplier<String> s = () -> { name; owner.name }; s.get() 
> }
>         c()
>     }
> }
> new C().q()
> {code}
> *Actual:* {{q()}} and {{r()}} throw {{GroovyCastException: Cannot cast object 
> 'C@...' with class 'C' to class 'groovy.lang.Closure'}}, and {{t()}} fails to 
> compile with "No such property: name for class: groovy.lang.Closure". 
> {{delegate}}, {{getOwner()}} and {{getDelegate()}} behave the same.
> *Expected:* the owner of a statically compiled native lambda is the enclosing 
> instance at any depth of nesting, as it is for a top-level lambda. So 
> {{owner}} and {{delegate}} should be typed as {{C}}: {{t()}} returns 'n', and 
> {{owner.maximumNumberOfParameters}} is rejected at compile time, as it is in 
> a top-level lambda.
> Cause: {{StaticTypeCheckingVisitor}} types {{owner}} and {{getOwner()}}, and 
> {{delegate}} without delegation metadata, as {{Closure}} whenever more than 
> one closure or lambda encloses the reference. A native lambda's owner is the 
> enclosing {{this}}, not the enclosing function. A closure, or a lambda 
> compiled as a closure (type-checked code, or no functional-interface target), 
> is still owned by the enclosing function.
> Verified on 4.0.33 (owner reference in a lambda inside a closure), 5.0.8, 
> 6.0.0 and master.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to