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

[Maurizio Cimadamore]

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

Maurizio

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
>>
>>
>