[jira] [Resolved] (GROOVY-9790) bootstrap method initialization exception raised when lambda parameter type is wrong

2020-10-28 Thread Daniel Sun (Jira) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-9790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Sun resolved GROOVY-9790.

Fix Version/s: 4.0.0-alpha-2
   3.0.7
 Assignee: Daniel Sun
   Resolution: Fixed

> bootstrap method initialization exception raised when lambda parameter type 
> is wrong
> 
>
> Key: GROOVY-9790
> URL: https://issues.apache.org/jira/browse/GROOVY-9790
> Project: Groovy
>  Issue Type: Bug
>  Components: Static compilation
>Affects Versions: 3.0.6
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 3.0.7, 4.0.0-alpha-2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The following code will raise BME
> {code:java}
> import java.util.stream.*
> @groovy.transform.CompileStatic
> def x() {
> IntStream.range(0, 2).forEach((Integer i) -> { assert 0 <= i && i < 2})
> // IntStream.range(0, 2).forEach(i -> { assert 0 <= i && i < 2}) // raise 
> BME too
> }
> x()
> {code}
> but the following code works well:
> {code:java}
> import java.util.stream.*
> @groovy.transform.CompileStatic
> def x() {
> IntStream.range(0, 2).forEach((int i) -> { assert 0 <= i && i < 2})
> }
> x()
> {code}
> *BME stacktrace:*
> {code:java}
> java.lang.BootstrapMethodError: bootstrap method initialization exception
>   at 
> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194)
>   at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315)
>   at 
> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:271)
>   at 
> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:261)
>   at ConsoleScript15.x(ConsoleScript15:5)
>   at 
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:318)
>   at ConsoleScript15.run(ConsoleScript15:8)
>   at 
> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:254)
>   at groovy.lang.GroovyShell.run(GroovyShell.java:360)
>   at groovy.lang.GroovyShell.run(GroovyShell.java:339)
>   at groovy.lang.GroovyShell.run(GroovyShell.java:166)
>   at groovy.lang.GroovyShell$run$0.call(Unknown Source)
>   at 
> groovy.console.ui.Console$_runScriptImpl_closure22.doCall(Console.groovy:1302)
>   at 
> groovy.console.ui.Console$_runScriptImpl_closure22.doCall(Console.groovy)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>   at 
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
>   at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
>   at 
> org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:263)
>   at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
>   at groovy.lang.Closure.call(Closure.java:412)
>   at groovy.lang.Closure.call(Closure.java:406)
>   at groovy.lang.Closure.run(Closure.java:493)
>   at java.base/java.lang.Thread.run(Thread.java:832)
> Caused by: java.lang.invoke.LambdaConversionException: Type mismatch for 
> instantiated parameter 0: class java.lang.Integer is not a subtype of int
>   at 
> java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.checkDescriptor(AbstractValidatingLambdaMetafactory.java:322)
>   at 
> java.base/java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:308)
>   at 
> java.base/java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:327)
>   at 
> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:127)
>   ... 25 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [groovy] danielsun1106 merged pull request #1409: GROOVY-9790: bootstrap method initialization exception raised when la…

2020-10-28 Thread GitBox 


danielsun1106 merged pull request #1409:
URL: https://github.com/apache/groovy/pull/1409


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (GROOVY-9796) Static type checker doesn't backtrack when solving generics

2020-10-28 Thread Christopher Smith (Jira) 


 [ 
https://issues.apache.org/jira/browse/GROOVY-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Smith updated GROOVY-9796:
--
Description: 
When a method pipeline involves generics, the static type checker is greedy and 
tends to be overly specific, producing errors when the correct answer involves 
relaxing to a common bound.


{code:groovy}
@CompileStatic
Number returnANumber() {
  Number number = Optional.of(1234 as Integer) // should infer Optional
orElse(42.0 as Double)
}
{code}

{code}
[Static type checking] - Cannot find matching method 
java.util.Optional#orElse(java.lang.Double). Please check if the declared type 
is correct and if the method exists.
{code}
Explicitly inserting a type witness {{Optional.of}} works.

Note: This _might_ be a duplicate of GROOVY-8103, but I'm unable to tell 
precisely. 3.0.6 was released one week after it was marked resolved. 
GROOVY-8961 is marked fixed in 3.0.6, but I'm having the problem there.

  was:
When a method pipeline involves generics, the static type checker is greedy and 
tends to be overly specific, producing errors when the correct answer involves 
relaxing to a common bound.


{code:groovy}
@CompileStatic
Number returnANumber() {
  Number number = Optional.of(1234 as Integer) // should infer Optional
orElse(42.0 as Double)
}
{code}

{code}
[Static type checking] - Cannot find matching method 
java.util.Optional#orElse(java.lang.Double). Please check if the declared type 
is correct and if the method exists.
{code}
Explicitly inserting a type witness `Optional.of` works.

Note: This _might_ be a duplicate of GROOVY-8103, but I'm unable to tell 
precisely. 3.0.6 was released one week after it was marked resolved. 
GROOVY-8961 is marked fixed in 3.0.6, but I'm having the problem there.


> Static type checker doesn't backtrack when solving generics
> ---
>
> Key: GROOVY-9796
> URL: https://issues.apache.org/jira/browse/GROOVY-9796
> Project: Groovy
>  Issue Type: Bug
>  Components: Static Type Checker
>Affects Versions: 3.0.6
>Reporter: Christopher Smith
>Priority: Major
>
> When a method pipeline involves generics, the static type checker is greedy 
> and tends to be overly specific, producing errors when the correct answer 
> involves relaxing to a common bound.
> {code:groovy}
> @CompileStatic
> Number returnANumber() {
>   Number number = Optional.of(1234 as Integer) // should infer 
> Optional
> orElse(42.0 as Double)
> }
> {code}
> {code}
> [Static type checking] - Cannot find matching method 
> java.util.Optional#orElse(java.lang.Double). Please check if the declared 
> type is correct and if the method exists.
> {code}
> Explicitly inserting a type witness {{Optional.of}} works.
> Note: This _might_ be a duplicate of GROOVY-8103, but I'm unable to tell 
> precisely. 3.0.6 was released one week after it was marked resolved. 
> GROOVY-8961 is marked fixed in 3.0.6, but I'm having the problem there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GROOVY-9796) Static type checker doesn't backtrack when solving generics

2020-10-28 Thread Christopher Smith (Jira) 
Christopher Smith created GROOVY-9796:
-

 Summary: Static type checker doesn't backtrack when solving 
generics
 Key: GROOVY-9796
 URL: https://issues.apache.org/jira/browse/GROOVY-9796
 Project: Groovy
  Issue Type: Bug
  Components: Static Type Checker
Affects Versions: 3.0.6
Reporter: Christopher Smith


When a method pipeline involves generics, the static type checker is greedy and 
tends to be overly specific, producing errors when the correct answer involves 
relaxing to a common bound.


{code:groovy}
@CompileStatic
Number returnANumber() {
  Number number = Optional.of(1234 as Integer) // should infer Optional
orElse(42.0 as Double)
}
{code}

{code}
[Static type checking] - Cannot find matching method 
java.util.Optional#orElse(java.lang.Double). Please check if the declared type 
is correct and if the method exists.
{code}
Explicitly inserting a type witness `Optional.of` works.

Note: This _might_ be a duplicate of GROOVY-8103, but I'm unable to tell 
precisely. 3.0.6 was released one week after it was marked resolved. 
GROOVY-8961 is marked fixed in 3.0.6, but I'm having the problem there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GROOVY-8248) MethodSelectionException when calling a overloaded method without arguments

2020-10-28 Thread Daniil Ovchinnikov (Jira) 


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

Daniil Ovchinnikov commented on GROOVY-8248:


[~bigehokie] take a look please

> MethodSelectionException when calling a overloaded method without arguments
> ---
>
> Key: GROOVY-8248
> URL: https://issues.apache.org/jira/browse/GROOVY-8248
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.4.10
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code}
> def methodWithOverload(a, b) {
> println "$a $b"
> }
> def methodWithOverload(a) {
> methodWithOverload(a, new Object())
> }
> methodWithOverload("hello", "world")
> methodWithOverload("hello")
> methodWithOverload() // MSE here
> {code}
> {noformat}
> Caught: org.codehaus.groovy.runtime.metaclass.MethodSelectionException: Could 
> not find which method methodWithOverload() to invoke from this list:
>   public java.lang.Object myscript#methodWithOverload(java.lang.Object)
>   public java.lang.Object myscript#methodWithOverload(java.lang.Object, 
> java.lang.Object)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)