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

[Archie Cobbs]

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

> Can you expand a bit more -- who's trying to access this (and then failing with NPE) ?

The compiler expects the parameter to have an associated symbol:

java.lang.NullPointerException: Cannot read field "kind" because "tree.sym" is null
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitIdent(Flow.java:3395)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2710)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitVarDef(TreeScanner.java:142)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitVarDef(Flow.java:3444)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1066)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:132)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:960)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:58)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:125)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitClassDef(Flow.java:3347)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:859)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.analyzeTree(Flow.java:3470)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.analyzeTree(Flow.java:3463)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:231)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1406)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
	at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:319)
	at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:178)
	at jdk.compiler.interim/com.sun.tools.javac.Main.compile(Main.java:66)
	at jdk.compiler.interim/com.sun.tools.javac.Main.main(Main.java:52)


I guess we could hack some placeholder.

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

You then get this problem when the outer class is generic:

RecvParam.java:24: error: the receiver name does not match the enclosing class type
        public void m4(Inner3<T> Inner3.this, short s) {
                                       ^
  required: Inner3<T>
  found:    Inner3


Plus, you still haven't dealt with any static context issues... (e.g., see unit test `/annotations/typeAnnotations/failures/common/receiver/StaticThings.java`).

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

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