Most specific method in diagnostic generation for overload resolution
vicente.romero at oracle.com
Tue Sep 26 17:56:44 UTC 2017
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:
>>> 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
>>> 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
>>>>> 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