RFR: 8335385: javac crash on unattributed piece of AST

[Jan Lahoda]

On Tue, 2 Jul 2024 19:16:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Consider the following sources:
>> 
>> //B.java
>> package p;
>> 
>> public class B {
>>     public interface I {}
>> }
>> 
>> 
>> Test.java
>> import p.B.I;
>> 
>> 
>> Then compile `B`, remove the `I` nested interface, and try to compile `Test` with the remaining classfiles of `B` on the classpath:
>> 
>> $ javac -d out B.java
>> $ rm out/p/B$I.class
>> $ javac -classpath out -XDdev Test.java
>> Test.java:1: error: cannot access I
>> import p.B.I;
>>           ^
>>   class file for p.B$I not found
>> 1 error
>> An exception has occurred in the compiler (24-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.NullPointerException: Cannot read field "owner" because "s.sym" is null
>>         at jdk.compiler/com.sun.tools.javac.comp.Check.isCanonical(Check.java:4264)
>>         at jdk.compiler/com.sun.tools.javac.comp.Check.checkCanonical(Check.java:4256)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doImport(TypeEnter.java:466)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:416)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.lambda$ensureImportsChecked$0(TypeEnter.java:165)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.finishImports(TypeEnter.java:217)
>>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.ensureImportsChecked(TypeEnter.java:165)
>>         at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:650)
>>         at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:600)
>>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1077)
>>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:948)
>>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
>>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
>>         at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
>>         at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>> printing javac parameters to: /tmp/javac.20240701_092709.args
>> 
>> 
>> The reason is that when the impo...
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2427:
> 
>> 2425:     Symbol findIdent(DiagnosticPosition pos, Env<AttrContext> env, Name name, KindSelector kind) {
>> 2426:         try {
>> 2427:             return checkNonExistentType(checkRestrictedType(pos, findIdentInternal(pos, env, name, kind), name));
> 
> should the new code be moved into `checkNonExistentType` so that all of its clients benefit from it?

The `CompletionFailure` happens inside `findIdentInternal` or `findIdentInTypeInternal`, so handling this in `checkNonExistentType` is too late, I'm afraid. I was thinking of having a method encapsulating the try-catch, but that would mean the code to lookup the type would need to be in a capturing lambda, which seemed a bit heavyweight for this place. But that would surely be doable, if preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19969#discussion_r1663582888