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

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

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

More information about the compiler-dev mailing list