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

Vicente Romero vicente.romero at oracle.com
Thu Nov 8 01:56:24 UTC 2018

I liked your suggestion thanks:


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

More information about the compiler-dev mailing list