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

[Maurizio Cimadamore]

On Fri, 6 Sep 2024 08:03:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1023:
>> 
>>> 1021:                 switch (sym.getKind()) {
>>> 1022:                     case FIELD, ENUM_CONSTANT -> {
>>> 1023:                         if (sym.name.equals(names._this) || sym.name.equals(names._super)) {
>> 
>> Not sure: don't we need super also for field access? E.g.
>> 
>> 
>> class A {
>>    Object o;
>> }
>> class B extends A {
>>     int o; // shadows A.o
>>     Object superO() { return super.o; }
>> }
>
> I wonder if a modelling where `super` is its own expression would be beneficial. E.g. like some kind of "virtual field" on `this`. E.g. one would load `this` and then access `super` onto it (and maybe there's a core op for _that_). Then the result is used for either a method receiver, or field access expression.

Although I suppose in my example, we still generate a `getfield` for `super.o`, just with a different symbolic description - so the generated model ends up being fine. I suppose I'm not 100% comfortable with the fact that the model here seems to capture a bytecode distinction (e.g. super calls use a special invocation mode, but super field access do not, so we only model the former), rather than a syntactic difference in the original source (e.g. for both method and field access, the `super` keyword is there).

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

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