RFR 8188144: regression in method reference type-checking
Vicente Romero
vicente.romero at oracle.com
Fri Sep 29 17:54:12 UTC 2017
looks good,
nit: why static methods? not strong about this but we usually favor
instance over static methods
Thanks,
Vicente
On 09/29/2017 12:42 PM, Maurizio Cimadamore wrote:
>
> Hi,
> here's a patch for a regression in method reference type checking:
>
> http://cr.openjdk.java.net/~mcimadamore/8188144/
>
> JLS 15.13.1 defines the process for resolving a method reference -
> this is a two step process, where two searches are performed. It is
> sometimes possible for both searches to produce a result - when that
> happens, there are a bunch of rules which tell us what search wins:
>
> " the first search produces a most specific method that is |static|,
> and the set of applicable methods produced by the second search
> contains no non-|static| methods, then the compile-time declaration is
> the most specified method of the first search"
>
> And again:
>
> "Otherwise, if the set of applicable methods produced by the first
> search contains no |static| methods, and the second search produces a
> most specific method that is non-|static|, then the compile-time
> declaration is the most specific method of the second search."
>
> Javac has been rectified to correctly implement this logic as part of:
>
> https://bugs.openjdk.java.net/browse/JDK-8068995
>
> However, in the degenerate case where both searches return _the same_
> method, the rectified logic doesn't work. This is caused by the fact
> that we use the resolved symbol to 'infer' which search (first or
> second?) gave us the desired result. Note that it is important for
> javac to know which search produced the result as that will affect
> code generation (is this a bound or an unbound method reference?).
>
> Since we already had all the desired information in the class called
> ReferenceLookupResult - introduced as part of JDK-8068995, I have
> tweaked the ReferenceChooser::result signature to return one of those
> guys instead of a plain Symbol - this allows us to reconstruct the
> correct picture before returning control to Attr.
>
> Cheers
> Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170929/518c4184/attachment.html>
More information about the compiler-dev
mailing list