RFR 8188144: regression in method reference type-checking
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Sep 29 16:42:17 UTC 2017
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/15ecf996/attachment.html>
More information about the compiler-dev
mailing list