Most specific method in diagnostic generation for overload resolution

[Vicente Romero]

On 09/26/2017 01:53 PM, Maurizio Cimadamore wrote:
>
>
> 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).

OK thanks for the background, so I guess once I have a word from Bernard 
regarding the change I did to his patch I will push it as it makes the 
output more readable

>
> Maurizio

Vicente

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