RFR: JDK-8210197: candidate selection during overload resolution can lead to unexpected results for diamond expressions

[Vicente Romero]

Hi,

Please review patch for [1] at [2]. The issue was can be explained with 
these two simple classes:

------------------------------------------------------------------------------------------------------
package pkg1;

public class MyClass<T> {
     protected MyClass() {}                // (i)
     protected MyClass(String s) {}    // (ii)
}

------------------------------------------------------------------------------------------------------

package pkg2;

import pkg1.*;

class Client {
     <T> void foo(MyClass<T> m) {}

     void bar() {
         foo(new MyClass<>(){});
     }
}

------------------------------------------------------------------------------------------------------

both constructors are protected and given that we are dealing with a 
diamond expression, speculative attribution is used. During speculative 
attribution, javac removes the class definition from the equation 
meaning that:
new MyClass<>(){} is rewritten as:
new MyClass<>()

the first expression has access to the protected constructors, the other 
one not.  So as both are protected, they are considered not accessible 
during overload resolution. Still constructor (i) is applicable but 
constructor (ii) is not applicable. So my proposal is to create an 
access error at Resolve::selectBest also for this case. Right now an 
access error is created only if no other method is found. When an access 
error is returned during overload resolution, the inaccessible symbol is 
still used and attached to the AST till the check phase can double check 
and issue an error or not. As during the check phase the diamond 
expression is attributed without rewriting, the compiler can then find 
out that constructor (i) is both applicable and accessible.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8210197
[2] http://cr.openjdk.java.net/~vromero/8210197/webrev.00/