RFR: 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
Maurizio Cimadamore
mcimadamore at openjdk.org
Sun May 11 10:14:51 UTC 2025
On Fri, 9 May 2025 21:48:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:
> > The changes look good -- but I wonder -- is there really no way to prevent javac from "going down the rabbit hole" and attempting to prove that `Foo.this` is a good/accessible enclosing this (via `resolveSelf`) ? E.g. it feels like javac shouldn't even be in that method for a receiver parameter.
>
> It happens at the start of `MemberEnter.checkReceiver()` where it needs to attribute the parameter to verify it has the correct type, and that means attributing the expression `Foo.this`. This seems like a reasonable thing to do at that point... so maybe the problem is that the early access check is happening then (during attribution) instead of later somehow?
My feeling is that at this point we should just attribute `Foo` -- and leave `this` alone. That is, `this` is just an extra syntactic token that is used to denote the receiver parameter name. Attributing it as `Foo.this` causes the compiler to think it's an outer `this` access, which this is not. So let's just type-check the type (and leave `this` off to the side) ? After all this code only wants to make sure the type before `.this` makes sense for the context in which the receiver parameter appears.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2869669494
More information about the compiler-dev
mailing list