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

[Vicente Romero]

On 11/8/18 10:00 AM, Maurizio Cimadamore wrote:
> Looks good, I would only change the name of the TreeMaker factory so 
> that it's clear that it's used by deferred attribution - e.g. 
> SpeculativeNewClass

ok I will do that locally and push it
>
> Maurizio

thanks,
Vicente

>
> On 08/11/2018 01:56, Vicente Romero wrote:
>> 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
>>>
>>>
>>