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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Nov 8 15:00:23 UTC 2018

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

More information about the compiler-dev mailing list