Most specific method in diagnostic generation for overload resolution

[Maurizio Cimadamore]

On 26/09/17 18:33, Vicente Romero wrote:
>
>
> On 09/26/2017 10:07 AM, Maurizio Cimadamore wrote:
>> Hi,
>> 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.
>>
>> 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).

Maurizio
>
>>
>> Maurizio
>>
>>
>> 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' - 
>>>> see
>>>> InapplicableSymbolsError::filterCandidates.
>>>>
>>>> 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?
>>>
>>> Thanks,
>>> Bernard
>>>
>>>> Maurizio
>>
>