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

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

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

   An implicit-this call in a closure to a method that `Closure` declares was 
resolved against every overload of that name, without looking at the arguments:
   
   ```groovy
   @groovy.transform.TypeChecked
   def test() {
       Closure<Object> c = { String a, String b -> b == null ? curry(a) : a + b 
}
       ((Closure) c('x', null))('y')
   }
   ```
   
   This fails with "Reference to method is ambiguous. Cannot choose between 
Closure#curry(Object[]) and Closure#curry(Object)"; dynamic Groovy returns 
`xy`. `rcurry`, `ncurry`, `trampoline()`, `andThenSelf()`, `composeSelf()` and 
`leftShift(Closure)` failed the same way, in 4.0.33, 5.0.8 and 6.0.0 too. A 
call whose arguments fit no `Closure` overload, such as `memoize('x')` or 
`getDelegate(1)` where the owner declares those methods, was bound to the 
closure's method (5.0.8 and later): under `@CompileStatic` the closure's method 
was called, and under `@TypeChecked` the call failed with a 
`GroovyCastException`.
   
   The closure's methods are now chosen with `chooseBestMethod` and the 
argument types (the GROOVY-11386 block of 
`StaticTypeCheckingVisitor.visitMethodCallExpression`). When none matches, the 
call goes through the normal delegate/owner lookup, as 
`ClosureMetaClass.invokeMethod` does at run time. Under `DELEGATE_ONLY`, 
`ClosureMetaClass` sends `curry`, `ncurry`, `rcurry`, `leftShift` and 
`rightShift` to the delegate, and the type checker now does the same 
(`CLOSURE_DELEGATE_ONLY_METHODS`); without that, the overload fix would have 
bound those calls to the closure.
   
   ## Tests
   
   `ClosuresSTCTest.testClosureOverloadedMethods`, 
`testClosureMethodWithoutMatchingArguments` and 
`testClosureDelegateOnlyCurryAndShiftMethods` fail without the change, in both 
`ClosuresSTCTest` and `ClosuresStaticCompileTest`. `groovy.transform.stc.*`, 
`org.codehaus.groovy.classgen.asm.sc.*`, `gls.closures.*` and 
`groovy.ClosureTest` pass. The Checkstyle and CodeNarc gates pass.
   




> STC rejects an implicit-this call in a closure to an overloaded Closure 
> method, such as curry(x), as ambiguous, and ignores argument types when 
> choosing the Closure method
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12662
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12662
>             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}
> @groovy.transform.TypeChecked // or @CompileStatic
> def test() {
>     Closure<Object> c = { String a, String b -> b == null ? curry(a) : a + b }
>     ((Closure) c('x', null))('y')
> }
> assert test() == 'xy'
> {code}
> *Actual:*
> {noformat}
> [Static type checking] - Reference to method is ambiguous. Cannot choose 
> between [groovy.lang.Closure<V> 
> groovy.lang.Closure#curry(java.lang.Object[]), groovy.lang.Closure<V> 
> groovy.lang.Closure#curry(java.lang.Object)]
> {noformat}
> *Expected:* 'xy', as in dynamic Groovy, which calls curry(Object) on the 
> enclosing closure. rcurry, ncurry, trampoline(), andThenSelf(), composeSelf() 
> and leftShift(Closure) fail the same way.
> The selection ignores argument types altogether. If the owner declares 
> memoize(String) or getDelegate(int), then memoize('x') or getDelegate(1) 
> inside a closure is bound to Closure.memoize() or Closure.getDelegate(). 
> Under @CompileStatic the closure's method is called. Under @TypeChecked the 
> inferred type is wrong, and the call fails with a GroovyCastException. 
> Dynamic Groovy calls the owner's method. Under DELEGATE_ONLY, 
> ClosureMetaClass sends curry, ncurry, rcurry, leftShift and rightShift to the 
> delegate, but the type checker binds them to the closure.
> Cause: for an implicit-this call in a closure, StaticTypeCheckingVisitor 
> takes every Closure method of that name (GROOVY-11386) without choosing among 
> them by argument type, and never falls back to the delegate or owner when 
> none of them accepts the arguments.
> Verified: 4.0.33 (ambiguity only), 5.0.8, 6.0.0 and master.



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

Reply via email to