known translation issues related to JEP 482

[Maurizio Cimadamore]

On 14/06/2024 18:04, Archie Cobbs wrote:
> Your change to the semantics of hasOuterInstance() happens to 
> invalidate my fix for JDK-8334248 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19705/files*diff-ce037c979a568d769d3064d15f94a75cd0311e3e0a9e7899f59d4f9283ad6ea8__;Iw!!ACWV5N9M2RV99hQ!L-9GAxHAzJt6lxEoIcD-NgGJuM7uictTascht11Ui5uc02DZuGr2sDg5IWBSv_Ei2Gq59ZhAZQhMq9hvL4QIKLPqhvnscg$> 
> but that's OK, the new semantics are more correct and I've rewritten 
> my fix to instead check for NOOUTERTHIS directly.

Thanks. I wonder... is the real problem here that 
Resolve::resolveImplicitThis doesn't skip over classes that have 
NOOUTERTHIS set? E.g. your patch just disables the check if we see 
NOOUTERTHIS... which is ok if the current class happens to have NO 
accessible enclosing instances. But what if there's *some* accessible 
enclosing instance?

Something like this:

```java
class Outer {
     void m() { }

     class Inner {
         Inner() {
             class Foo { void g() { m(); } }
             super();
             class Bar { static void r() { new Foo(); } };
         }
     }
}

```

Btw, it seems like this code crashes javac (even with both patches 
applies). I don't think this code should be allowed at all (you can't 
create the local Foo from the static Bar::r). So, this is related to the 
bug you mentioned, and I believe we need checks for the innermost 
accessible enclosing instance here.

Maurizio


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240614/3ec4d2bc/attachment.htm>