[code-reflection] RFR: Super expressions [v2]

[Paul Sandoz]

On Fri, 6 Sep 2024 21:06:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Perhaps it's an implementation detail and does not matter? I was unsure.
>> 
>> Sorry, perhaps I was getting too ahead of myself. But it seems to me that `resolveToMember(lookup)` will pass the `InvokeClass` kind by default. This will cause (if I'm correct) a `findStatic` lookup, which might fail if the type-variable has a non-static method owner?
>
> Ah! I missed that the code is trying `static` first and then follows up with a `virtual` lookup if that one fails. I wonder if that could lead to a situation where we resolve to the wrong method e.g. if we have something like this:
> 
> 
> class A {
>     static void m() { }
> }
> 
> class B extends A {
>     <X> void m() { }
> }
> 
> 
> But this seems disallowed by the overriding/hiding rules. (it's probably possible to have classfiles like that though - e.g. when generated via classfile API).

In general this behavior is probably too sneaky :-) I think we would need to resolve using class and instance kinds and if both resolve successfully pick the most specific.

For this `TypeVarRef` case i believe the method reference should refer to a declared method on the referencing class, it's the owner. If so we can constrain the resolution. (I realize my prior code example wrong, it should compare the resolved class of the method ref's referencing class.)

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/221#discussion_r1747753312