hg: lambda/lambda/langtools: 8016175: Add bottom-up type-checking support for unambiguous method references

[Ali Ebrahimi]

Hi,


On Sat, Jun 29, 2013 at 4:24 PM, maurizio cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  On 28-Jun-13 5:59 PM, Ali Ebrahimi wrote:
>
>  Hi Maurizio,
>  In test MethodReference71 I don't get why g(this::m2) is ambiguous.
>  please clarify this for me. thanks in advance.
>
>
> It's not ambiguous, sorry for the typo in the test; however it's
> erroneous, as the compiler doesn't have enough information to type-check
> the method reference.
>
I think this is more than typo in test case  since test output file says
other thing. however, I have not tried that yet.

+++ b/test/tools/javac/lambda/MethodReference71.out	Fri Jun 28
11:54:17 2013 +0100
@@ -0,0 +1,3 @@
+MethodReference71.java:24:10: compiler.err.ref.ambiguous: g,
kindname.method, <Z>g(MethodReference71.F<Z>), MethodReference71,
kindname.method, <Z>g(MethodReference71.G<Z>), MethodReference71
+MethodReference71.java:24:11: compiler.err.prob.found.req:
(compiler.misc.cyclic.inference: Z)
+2 errors



>
> If, however, the method reference is unambiguous _and_ not a varargs (as
> the first case), the compiler will go bottom up and 'unstick' the method
> reference.
>
> We decided against the varargs case as, in the general case, that would
> require support for disjunctive type inference, and we wanted to limit the
> scope of the change at this point of the release.
>
so support for this case is on the desk for future. Ya?

what about reverse case:

class MethodReference71b {
 interface F<X> {
     void m(X... x);
 }


 void m1(Integer i) { }

 <Z> void g(F<Z> f) { }

 void test() {
     g(this::m1); //?
 }

}

Best Regards
Ali Ebrahimi