Most specific method in diagnostic generation for overload resolution
maurizio.cimadamore at oracle.com
Tue Sep 26 17:53:01 UTC 2017
On 26/09/17 18:33, Vicente Romero wrote:
> On 09/26/2017 10:07 AM, Maurizio Cimadamore wrote:
>> I was just pointing out that we already seem to have a piece of
>> functionality to filter candidates, so the design for the fix should
>> consider as to whether reuse existing machinery or coming up with new
>> One can argue this in both ways - on the one hand, reusing same
>> machinery is more economical - on the one hand, one could argue that
>> the existing machinery is or filtering out 'near misses', while
>> overridden method should never appear in the candidate set in the
>> first place (as per JLS).
> I see, so then it seems like a more important bug could be lurking in
> overload resolution
No bug, while it's true that overload resolution in javac exposes a big
set of candidates than in the JLS, that's just how javac works. When you
look for a method 'm' in C, javac will look for all candidates in C, and
only recur to C's supertypes if nothing is found - which is something
that matches the JLS behavior.
This approach has pros and cons; on the one hand is dead simple, and
does not require membership calculation ahead of overload resolution, so
it's fast. On the other hand, since candidates *must be accessible
members*, at some point javac will have to check if what's on its hands
is really a JLS-worthy candidate. So this could lead to a program flow
that is hard to follow (e.g. a method seems applicable, but then javac
at a later point says - you know what? I should not even look at you
from a JLS perspective).
That said, this is just how javac works - and it's defo outside the
scope of this fix to alter that behavior. In fact, I believe altering
that behavior will require a significant amount of work, and, likely,
its own JEP (should we ever decide to bring javac and JLS more in sync
in this regard).
>> On 26/09/17 14:57, B. Blaser wrote:
>>> Hi Maurizio,
>>> On 26 September 2017 at 13:17, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>> One comment - we already have a method for 'filtering candidates' -
>>>> Currently, that method is simply discarding methods with wrong
>>>> arity if the
>>>> compact diagnostics are enabled (default since JDK 8).
>>>> I wonder if we could add to this method so that it would also
>>>> filter out
>>>> overridden methods? That way you could use the compiler flag to
>>>> enable/disable the filtering.
>>> This would probably be possible, we have to look at that too.
>>> But is this really necessary to disable this filtering?
>>> Do we really need to see all the overridden methods?
More information about the compiler-dev