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

[Vicente Romero]

I liked your suggestion thanks:

http://cr.openjdk.java.net/~vromero/8210197/webrev.02/

On 11/7/18 6:44 PM, Maurizio Cimadamore wrote:
>
> On 07/11/2018 13:40, Vicente Romero wrote:
>> right I had the initial idea of going for this alternative first and 
>> wrote a patch see [3], but later convinced myself that the patch I 
>> sent in the original mail was the way to go :(. So [3] is a fix on 
>> the lines of setting diamondEnv.info.selectSuper to true for diamonds 
>> that had a class definition attached even during speculative 
>> attribution. But the patch seemed a bit hacky to me. I guess that we 
>> should probably just add a field to JCNewClass to indicate if the 
>> ClassDef part has been removed just during speculative attribution as 
>> a cleaner solution, what do you think?
>
> Yep that would indeed be a good solution. As usual, if you want to 
> avoid having a field, I guess you could also have a predicate method 
> on JCNewClass which always return 'false' but which the deferred 
> copier overrides to return 'true' so that you can piggy back on that?
>
> Maurizio
>
>