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

[Maurizio Cimadamore]

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