Most specific method in diagnostic generation for overload resolution

[Vicente Romero]

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

>
> 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
>