RFR: 8356551: Javac rejects receiver parameter in constructor of local class in early construction context

Archie Cobbs acobbs at openjdk.org
Mon May 12 22:44:53 UTC 2025


On Mon, 12 May 2025 15:32:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I tried out that approach in [this branch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt). I'm reaching the limits of my grasp so this may not be the simplest way to do this. AFAICT we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later) and (b) do the static check stuff.
>>> 
>>> Let me know which version you prefer, or any other thoughts.
>> 
>> Thanks for the experiment.
>> My general feeling is that we can get away with a lot less. The code in `checkReceiver` is sending `Foo.this` into attribution. But then it's not really using the full results of the attribution -- instead it's just looking at the type qualifier, and enforcing that this type is the same as the enclosing instance type:
>> 
>> 
>> checkType(tree.nameexpr, outertype, Errors.IncorrectConstructorReceiverName(outertype, tree.nameexpr.type));
>> 
>> (see `tree.nameexpr.type`).
>> 
>> So, my idea was to simply compute `tree.nameexpr.type` by calling `Attr::attribType` on the qualifier, and then keep `checkReceiver` the same as it is today. This also should not need to add any new method in `Resolve`.
>
>> we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later)
> 
> Can you expand a bit more -- who's trying to access this (and then failing with NPE) ?

@mcimadamore thanks for the review - and for the idea.

I have some fuzziness on exactly how `AttrContext` is supposed to be used, which is why I didn't go that route originally. `AttrContext` seems to correspond to lexical scopes, but here we want to "pass a note" with a narrower focus, i.e., just a variable declaration.

But maybe I'm being to pedantic. [This patch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt2) seems to work - what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2874362003


More information about the compiler-dev mailing list