Most specific method in diagnostic generation for overload resolution

Vicente Romero vicente.romero at
Tue Sep 26 17:33:11 UTC 2017

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

More information about the compiler-dev mailing list