known translation issues related to JEP 482

[Archie Cobbs]

On Fri, Jun 14, 2024 at 12:33 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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?
>
My current understanding is that my fix is correct because the compiler
checks for what it calls an "implicit this" - which we would describe as an
"immediate enclosing instance" - separately from non-immediate enclosing
instances.

The reason I say this is that before I made this adjustment (from checking
hasOuterInstance() → NOOUTERTHIS == 0) the following program failed to
compile:

$ cat EarlyLocalTest3.java
public class EarlyLocalTest3 {

    class Test {
        Test() {
            class InnerLocal { }
            Runnable r = InnerLocal::new;
            r.run();
            super();
        }
    }
}
$ javac -enable-preview --release 24 EarlyLocalTest3.java
../test/langtools/tools/javac/SuperInit/EarlyLocalTest3.java:6: error:
cannot reference this before supertype constructor has been called
            Runnable r = InnerLocal::new;
                         ^

The compiler is detecting that InnerLocal has an outer instance (
EarlyLocalTest3) and throwing an error, but that's incorrect because the (
*non-immediate*) outer instance for EarlyLocalTest3 is actually accessible
at that location.

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

So yes I also see the compiler crashing on that example but I think that
may be separate from the issue above...? I don't fully understand this one
yet.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240614/93b26152/attachment.htm>